From bryan at serverstack.com Sat Feb 1 00:38:57 2014 From: bryan at serverstack.com (Bryan Socha) Date: Fri, 31 Jan 2014 19:38:57 -0500 Subject: Updated ARIN allocation information In-Reply-To: References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> Message-ID: has it be clarified by arin on why they are going to allocate /28s? seems a faster way to waste ipv4 space with unusable ip addresses? The only thing I can think of is micro allocations for IX points. *Bryan Socha* Network Engineer 646.450.0472 | *bryan at serverstack.com * *ServerStack* | Scale Big On Fri, Jan 31, 2014 at 6:58 PM, William Herrin wrote: > On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson wrote: > > What I fail to understand from this thread is the apparent expectation > > that these smaller-than-/24 microscopic delegations from ARIN will be > > popular. > > Hi Tore, > > There is every expectation that they will be unpopular. They're a > hedge against the possibility of a grueling last-minute IPv6 > conversion following a failed IPv4 market. They're something that can, > with difficulty, be made to work. They serve no other purpose. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From rbf+nanog at panix.com Sat Feb 1 01:03:29 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Fri, 31 Jan 2014 19:03:29 -0600 Subject: Updated ARIN allocation information In-Reply-To: <3F5D9D08-A27B-45BD-9145-51CB508CE0B6@delong.com> References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <3F5D9D08-A27B-45BD-9145-51CB508CE0B6@delong.com> Message-ID: <20140201010329.GA8654@panix.com> On Fri, Jan 31, 2014 at 05:10:51AM -0800, Owen DeLong wrote: > > > A /8 slot costs as much as a /28 slot to hold process etc. A routing > > slot is a routing slot. The *only* reason this isn't a legal problems > > at the moment is people can still get /24s. The moment /24's aren't > > readily available and they are forced into using this range anyone > > filtering on /24 in this range is leaving themselves open to lawsuits. > > On what basis? How do you have the right to force me to carry your route on > my network? Especially in light of the recent strike-down of the net neutrality > rules? > > > Now as this range is allocated for transition to IPv6 a defence for > > edge networks may be "we can reach all their services over IPv6" > > but that doesn't work for transit providers. Eyeball networks would > > need to ensure that all their customers had access to IPv6 and even > > that may not be enough. > > Please point to the law which requires a transit provider to provide transit > to every tiny corner of every internet. Speaking only with respect to the US: I am aware of no such law. However, I am aware of a law that makes it unlawful for a bunch of large providers who already have large blocks of space to collude to prevent new entrants into the market by refusing to carry their routes. If the guy with the /28 he can't route alleges that that's what's happening, there are lots of arguments on the other side the ISPs with the filters could make. They've been filtering at /24 for a lot longer than it started to seriosuly harm new entrants into the market ... there was never any formal agreement to filter at /24; it just happened (but everyone ended up filtering at /24 ... that wasn't just coincidence) ... there are real technical reasons for limiting FIB size ... and so on. I don't know who would win the anti-trust lawsuit, but I wouldn't consider it a slam dunk for the ISPs doing the filtering. I don't expect there to actually be such a lawsuit. Among other things, buying a /24 will likely be cheaper than litigating this, so the only way it gets to trial is an organization litigating on principle. And, as I said, I'm not convinced the filtering providers lose if there is one. But anytime the big guys collectively have a policy that keeps out the new entrants, there's anti-trust exposure. -- Brett From owen at delong.com Sat Feb 1 01:14:37 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 31 Jan 2014 20:14:37 -0500 Subject: Updated ARIN allocation information In-Reply-To: References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> Message-ID: I will attempt to clarify this once more... When I wrote the policy which created this set-aside space, it was, as Bill has said, intended as a hedge to provide minimal resources for organizations that are unable to obtain larger IPv4 blocks through any normal mechanism (standard allocation/assignment, transfer, market, etc.) and desperately need some space which they can hopefully get routed to support the bare minimum IPv4 connectivity for their IPv6 environment. I expect that if use of these blocks does become necessary, then routing them will almost certainly be the least of the problems we face in that circumstance. It is my sincere hope that we come to our senses and implement IPv6 sufficiently that these blocks are never needed. However, as the saying goes, I am hoping for the best and planning for the worst. The ARIN community overwhelmingly supported this idea at the time and that is why we set aside the block in question. In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. Owen > On Jan 31, 2014, at 7:38 PM, Bryan Socha wrote: > > has it be clarified by arin on why they are going to allocate /28s? seems > a faster way to waste ipv4 space with unusable ip addresses? The only > thing I can think of is micro allocations for IX points. > > *Bryan Socha* > Network Engineer > 646.450.0472 | *bryan at serverstack.com * > > *ServerStack* | Scale Big > > >> On Fri, Jan 31, 2014 at 6:58 PM, William Herrin wrote: >> >>> On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson wrote: >>> What I fail to understand from this thread is the apparent expectation >>> that these smaller-than-/24 microscopic delegations from ARIN will be >>> popular. >> >> Hi Tore, >> >> There is every expectation that they will be unpopular. They're a >> hedge against the possibility of a grueling last-minute IPv6 >> conversion following a failed IPv4 market. They're something that can, >> with difficulty, be made to work. They serve no other purpose. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> From bryan at serverstack.com Sat Feb 1 01:53:12 2014 From: bryan at serverstack.com (Bryan Socha) Date: Fri, 31 Jan 2014 20:53:12 -0500 Subject: Updated ARIN allocation information In-Reply-To: References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> Message-ID: I get the idea behind it, but it really has no real world usage. I can still find 15 year old swips from people with /8s who keep getting more addresses. Break out the audits before their next blocks. From george.herbert at gmail.com Sat Feb 1 03:10:18 2014 From: george.herbert at gmail.com (George William Herbert) Date: Fri, 31 Jan 2014 19:10:18 -0800 Subject: Updated ARIN allocation information In-Reply-To: References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> Message-ID: <2344BD6F-E4B4-45E4-AFB1-741248194D59@gmail.com> Without making a policy proposal, (yet), it might make sense to have a suggestion to ARIN that if it *does* end up allocating multiple /28s from one /24 intermediate, that the /24 be regionally reserved so that all sub-blocks are physically nearby and could collaborate on a cooperative /24 global announcement and internal side split-out... -george william herbert george.herbert at gmail.com Sent from Kangphone On Jan 31, 2014, at 5:14 PM, Owen DeLong wrote: > I will attempt to clarify this once more... > > When I wrote the policy which created this set-aside space, it was, as Bill has said, intended as a hedge to provide minimal resources for organizations that are unable to obtain larger IPv4 blocks through any normal mechanism (standard allocation/assignment, transfer, market, etc.) and desperately need some space which they can hopefully get routed to support the bare minimum IPv4 connectivity for their IPv6 environment. > > I expect that if use of these blocks does become necessary, then routing them will almost certainly be the least of the problems we face in that circumstance. > > It is my sincere hope that we come to our senses and implement IPv6 sufficiently that these blocks are never needed. However, as the saying goes, I am hoping for the best and planning for the worst. The ARIN community overwhelmingly supported this idea at the time and that is why we set aside the block in question. > > In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. > > Owen > > >> On Jan 31, 2014, at 7:38 PM, Bryan Socha wrote: >> >> has it be clarified by arin on why they are going to allocate /28s? seems >> a faster way to waste ipv4 space with unusable ip addresses? The only >> thing I can think of is micro allocations for IX points. >> >> *Bryan Socha* >> Network Engineer >> 646.450.0472 | *bryan at serverstack.com * >> >> *ServerStack* | Scale Big >> >> >>> On Fri, Jan 31, 2014 at 6:58 PM, William Herrin wrote: >>> >>>> On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson wrote: >>>> What I fail to understand from this thread is the apparent expectation >>>> that these smaller-than-/24 microscopic delegations from ARIN will be >>>> popular. >>> >>> Hi Tore, >>> >>> There is every expectation that they will be unpopular. They're a >>> hedge against the possibility of a grueling last-minute IPv6 >>> conversion following a failed IPv4 market. They're something that can, >>> with difficulty, be made to work. They serve no other purpose. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 > From mpalmer at hezmatt.org Sat Feb 1 03:30:00 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 1 Feb 2014 14:30:00 +1100 Subject: Updated ARIN allocation information In-Reply-To: References: <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131212956.GC9822@hezmatt.org> Message-ID: <20140201033000.GJ9822@hezmatt.org> On Fri, Jan 31, 2014 at 03:10:56PM -0800, Owen DeLong wrote: > On Jan 31, 2014, at 1:29 PM, Matt Palmer wrote: > > Imagine one of the big players saying, "we're going to charge you $X per > > route you send to us" (just like transit agreements that state, "we will > > charge you $X/GB of traffic"), or "your contract allows you to send us N > > routes" (just like, "your contract allows you to send us N Gb of traffic"). > > About 15 minutes later everyone else would start doing it, to recoup the > > costs of sending routes to that provider. Peering would be considered not > > only if the volume of traffic was mutually advantageous, but also if the > > routes exchanged were mutually advantageous. > > That?s the optimistic outcome. The pessimistic outcome is that they get > rapidly depeered by everyone unwilling to pay $X/GB and then start losing > customers because their customers can no longer reach anyone else?s > customers through them. That doesn't mean someone somewhere wouldn't try it. But I doubt it would be done in such a heavy-handed manner as to incur that sort of reaction. There are a bunch of ways it could be done quietly and without too much fuss. Vague language about "reasonable route volume" would be the easiest to slip under the radar, and if the cost of additional routes is below what your costs of changing providers would be, you'll almost certainly just wear it. Similar language could also be a big stick against excessive deagg, so there's a potential upside there, too. The blow could very easily be softened, too, by offering to pay all your customer for the routes they accept *from* you -- even setting it up so it was revenue neutral (in the beginning, at least...) so people get used to the idea. Hell, I could see it pitched as an up-sell: pay us $$$ and we'll accept your /28, and pass some of that moolah along to others so they'll do it too. Once it's in place for that, just keep shortening the masklen over time for what you can announce for free (presumably as fragmentation due to sale of blocks increases route volume). If Mark Andrews' assertion comes to pass, that legal action is taken against those unwilling to accept longer prefixes, I'd expect this sort of scheme to come to pass *very* quickly. If you're willing to accept routes from all comers, just in exchange for payment to cover costs incurred, then nobody can claim restraint of trade or cartel-like behaviour. If things got really hairy, providers could use their netflow data and some BigData(TM) analytics to work out the "value" vs the "cost" of every route they were carrying, and drop those who didn't make the grade (where you could increase the "value" of your route by paying for it). If there's one thing the commercial Internet has demonstrated, is that there isn't a business model so weird that *someone* won't try it. > The reality probably lies somewhere in between. I suspect whoever chooses > to conduct this little experiment first should be prepared for substantial pain. There's no possible upside unless there's some risk. I'm surprised nobody's tried this already, the more I think about it. Time to raise some VC, perhaps! - Matt -- Of course, I made the mistake of showing [a demo application] off to my boss, who showed it off to his boss, and suddenly I couldn't reboot my desktop box without getting a change control approved. -- Derick Siddoway, in a place that doesn't exist From Valdis.Kletnieks at vt.edu Sat Feb 1 05:08:20 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 01 Feb 2014 00:08:20 -0500 Subject: Updated ARIN allocation information In-Reply-To: Your message of "Fri, 31 Jan 2014 15:10:56 -0800." References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131212956.GC9822@hezmatt.org> Message-ID: <22587.1391231300@turing-police.cc.vt.edu> On Fri, 31 Jan 2014 15:10:56 -0800, Owen DeLong said: > That?s the optimistic outcome. The pessimistic outcome is that they get > rapidly depeered by everyone unwilling to pay $X/GB and then start losing > customers because their customers can no longer reach anyone else?s > customers through them. Maybe I need to buy stock in General Mills, I forsee a run on Betty Crocker cake mixes... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From owen at delong.com Sat Feb 1 05:27:16 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 31 Jan 2014 21:27:16 -0800 Subject: Updated ARIN allocation information In-Reply-To: <20140201010329.GA8654@panix.com> References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <3F5D9D08-A27B-45BD-9145-51CB508CE0B6@delong.com> <20140201010329.GA8654@panix.com> Message-ID: On Jan 31, 2014, at 5:03 PM, Brett Frankenberger wrote: > On Fri, Jan 31, 2014 at 05:10:51AM -0800, Owen DeLong wrote: >> >>> A /8 slot costs as much as a /28 slot to hold process etc. A routing >>> slot is a routing slot. The *only* reason this isn't a legal problems >>> at the moment is people can still get /24s. The moment /24's aren't >>> readily available and they are forced into using this range anyone >>> filtering on /24 in this range is leaving themselves open to lawsuits. >> >> On what basis? How do you have the right to force me to carry your route on >> my network? Especially in light of the recent strike-down of the net neutrality >> rules? >> >>> Now as this range is allocated for transition to IPv6 a defence for >>> edge networks may be "we can reach all their services over IPv6" >>> but that doesn't work for transit providers. Eyeball networks would >>> need to ensure that all their customers had access to IPv6 and even >>> that may not be enough. >> >> Please point to the law which requires a transit provider to provide transit >> to every tiny corner of every internet. > > Speaking only with respect to the US: > > I am aware of no such law. > > However, I am aware of a law that makes it unlawful for a bunch of > large providers who already have large blocks of space to collude to > prevent new entrants into the market by refusing to carry their routes. > Sure? The Sherman Anti-Trust act. However, in order to bring a successful action under that act, one must prove that they colluded on the decision, rather than simply arriving at that decision independently. Since the current status quo is not carrying longer routes in general, it would be pretty hard to show that they colluded to avoid changing their policy. > If the guy with the /28 he can't route alleges that that's what's > happening, there are lots of arguments on the other side the ISPs with > the filters could make. They've been filtering at /24 for a lot longer > than it started to seriosuly harm new entrants into the market ... > there was never any formal agreement to filter at /24; it just happened > (but everyone ended up filtering at /24 ... that wasn't just > coincidence) ... there are real technical reasons for limiting FIB > size ... and so on. I don't know who would win the anti-trust lawsuit, > but I wouldn't consider it a slam dunk for the ISPs doing the > filtering. In the current regulatory environment with the current US courts, I?d say it?s pretty close to a slam dunk. However, IANAL and YMMV definitely applies here. As a practical matter, it?s also awfully expensive for the little guy to bring enough lawyers to bear on one of the large providers to stand a chance of not being simply buried in procedural paperwork and discovery. The little guy would have to have pretty strong backing or pretty deep pockets to survive the process. > I don't expect there to actually be such a lawsuit. Among other > things, buying a /24 will likely be cheaper than litigating this, so > the only way it gets to trial is an organization litigating on > principle. And, as I said, I'm not convinced the filtering providers > lose if there is one. But anytime the big guys collectively have a > policy that keeps out the new entrants, there's anti-trust exposure. Only if you can prove collusion. For civil matters, it?s just by preponderance of the evidence, but if the DoJ or some District Attorney or Attorney General decides to take the matter up as a criminal case, then the burden shifts to beyond a reasonable doubt. As much as I wish there were a way to require the big guys to be nice to the little guys, the reality is that the precedent such a case would set (being able to require a network to carry arbitrary traffic whether or not doing so is in that networks own best interest and regardless of the cost/benefit ratio, etc.) is a very dangerous precedent. Once that one is on the books, imagine how the big guys could use it to bankrupt the little guys? The other option, of course, is that the big guys simply start charging the registered prefix holder for every route they accept. Then, they are free to offer discounts up to 100% to any providers they choose to offer such discounts to, but the little guys are still shafted. Bottom line, the big guys have enough resources and know how to play the regulatory and litigation games well enough that I just don?t see the little guy achieving anything but a pyrrhic victory at best. Owen From tore at fud.no Sat Feb 1 11:44:58 2014 From: tore at fud.no (Tore Anderson) Date: Sat, 01 Feb 2014 12:44:58 +0100 Subject: Updated ARIN allocation information In-Reply-To: References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> Message-ID: <52ECDE3A.3060108@fud.no> * Owen DeLong > In answer to Tore's statement, this block does not apply the standard > justification criteria and I think you would actually be quite hard > pressed to justify a /24 from this prefix. In most cases, it is > expected that these would be the IPv4 address pool for the public > facing IPv4 side of a NAT64 or 464xlat service. Most organizations > probably only need one or two addresses and so would receive a /28. > It is expected that each of these addresses likely supports several > thousand customers in a service provider environment. This latter expectation of over-subscription is not echoed by the policy text itself. One of the valid usage examples mentioned (?key dual stack DNS servers?) would also be fundamentally incompatible with an requirement of over-subscription. If you look at the common transitional technologies you'll see that not even all of them do support over-subscription. In alphabetical order: - 6RD: No over-subscription possible, would require at least one IPv4 address per subscriber plus additional addressing required for the transport/access network. - 6PE/6VPE: No over-subscription possible, the infrastructure must be numbered normally with IPv4. - DS-Lite (AFTR): Over-subscription possible, but it's entirely reasonable to want to make the ratio as low as possible, in order to provide as many source ports as possible to the subscriber, to ease abuse handling, and so on. - MAP: Similar to DS-Lite, but is less flexible with regards to over-subscription, as all users in a MAP domain must get the same amount of ports. Thus the maximum over-subscription you can achieve is limited by your most active subscriber in his peak period of use, i.e., if you have a subscriber whose usage peaks to 20k ports, then that MAP domain can only support a 2:1 over-subscription ratio. MAP can also be configured in a not over-subscribed 1:1 mode. - NAT64: Same as DS-Lite. - SIIT: No over-subscription possible, as it's by design a 1:1 mapping. That said, the policy language does say ?ARIN staff will use their discretion when evaluating justifications?. So I suppose it is theoretically possible that the ARIN staff will do their best Dr. Evil impression, coming up with a big number N, and require requestors to have a N:1 over-subscription ratio to qualify. However, that would be better described as indiscretion, not discretion, IMHO. After all, the RIRs are book-keepers, not network operators; if a network operator makes a reasonable request, it isn't the RIR's place to second-guess their network deployment. If ARIN is doing that, they're overstepping. So in summary it seems to me that it is pretty easy to make a reasonable request for a /24 under this particular policy, and especially considering the immense routing benefit the /24 will have over all the other possible prefix lengths that can be requested (persuading providers/peers to accept /28s might be done on a small scale, but just won't work if you need global connectivity, and global connectivity is what end users expect), the only realistic outcome I can see is that [almost] all the requestors will go ahead and ask for the /24. We'll just have to wait and see, I guess. Tore From owen at delong.com Sat Feb 1 13:42:20 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 1 Feb 2014 05:42:20 -0800 Subject: Updated ARIN allocation information In-Reply-To: <52ECDE3A.3060108@fud.no> References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> <52ECDE3A.3060108@fud.no> Message-ID: While the policy text does not spell out a list of technologies, I believe that the clear intent of the community from the discussions and from the examples given in the policy text was for minimal IPv4 allocations to support the transition process. While no ratio is given in the policy text, I doubt that a ?we have 200 customers wanting to do 6RD? would be accepted as justification for a /24. However, I am merely speculating here. I don?t have any direct answers from ARIN staff about how the policy would be interpreted. My statements are strictly my own personal interpretation of the community intent and an expression of my intent as the author of the policy. Owen On Feb 1, 2014, at 3:44 AM, Tore Anderson wrote: > * Owen DeLong > >> In answer to Tore's statement, this block does not apply the standard >> justification criteria and I think you would actually be quite hard >> pressed to justify a /24 from this prefix. In most cases, it is >> expected that these would be the IPv4 address pool for the public >> facing IPv4 side of a NAT64 or 464xlat service. Most organizations >> probably only need one or two addresses and so would receive a /28. >> It is expected that each of these addresses likely supports several >> thousand customers in a service provider environment. > > This latter expectation of over-subscription is not echoed by the policy > text itself. One of the valid usage examples mentioned (?key dual stack > DNS servers?) would also be fundamentally incompatible with an > requirement of over-subscription. If you look at the common transitional > technologies you'll see that not even all of them do support > over-subscription. In alphabetical order: > > - 6RD: No over-subscription possible, would require at least one IPv4 > address per subscriber plus additional addressing required for the > transport/access network. > > - 6PE/6VPE: No over-subscription possible, the infrastructure must be > numbered normally with IPv4. > > - DS-Lite (AFTR): Over-subscription possible, but it's entirely > reasonable to want to make the ratio as low as possible, in order to > provide as many source ports as possible to the subscriber, to ease > abuse handling, and so on. > > - MAP: Similar to DS-Lite, but is less flexible with regards to > over-subscription, as all users in a MAP domain must get the same amount > of ports. Thus the maximum over-subscription you can achieve is limited > by your most active subscriber in his peak period of use, i.e., if you > have a subscriber whose usage peaks to 20k ports, then that MAP domain > can only support a 2:1 over-subscription ratio. MAP can also be > configured in a not over-subscribed 1:1 mode. > > - NAT64: Same as DS-Lite. > > - SIIT: No over-subscription possible, as it's by design a 1:1 mapping. > > That said, the policy language does say ?ARIN staff will use their > discretion when evaluating justifications?. So I suppose it is > theoretically possible that the ARIN staff will do their best Dr. Evil > impression, coming up with a big number N, and require requestors to > have a N:1 over-subscription ratio to qualify. However, that would be > better described as indiscretion, not discretion, IMHO. After all, the > RIRs are book-keepers, not network operators; if a network operator > makes a reasonable request, it isn't the RIR's place to second-guess > their network deployment. If ARIN is doing that, they're overstepping. > > So in summary it seems to me that it is pretty easy to make a reasonable > request for a /24 under this particular policy, and especially > considering the immense routing benefit the /24 will have over all the > other possible prefix lengths that can be requested (persuading > providers/peers to accept /28s might be done on a small scale, but just > won't work if you need global connectivity, and global connectivity is > what end users expect), the only realistic outcome I can see is that > [almost] all the requestors will go ahead and ask for the /24. We'll > just have to wait and see, I guess. > > Tore From jcurran at arin.net Sat Feb 1 15:16:19 2014 From: jcurran at arin.net (John Curran) Date: Sat, 1 Feb 2014 15:16:19 +0000 Subject: Updated ARIN allocation information In-Reply-To: References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> <52ECDE3A.3060108@fud.no> Message-ID: On Feb 1, 2014, at 8:42 AM, Owen DeLong wrote: > While the policy text does not spell out a list of technologies, I believe > that the clear intent of the community from the discussions and from > the examples given in the policy text was for minimal IPv4 allocations > to support the transition process. While no ratio is given in the policy > text, I doubt that a ?we have 200 customers wanting to do 6RD? would > be accepted as justification for a /24. > > However, I am merely speculating here. I don?t have any direct answers > from ARIN staff about how the policy would be interpreted. My statements > are strictly my own personal interpretation of the community intent and > an expression of my intent as the author of the policy. Owen - To be clear, ARIN is inclined to approve requests whenever it is possible to do such in compliance with policy. Given the leeway in the present policy text, we're likely to approve any reasonable request which is made under this policy, and it would not be difficult to imagine requests for /24 being approved as a result. If pooled use/oversubscription or specific technologies are required, it would be very helpful to provide additional policy text to staff. Thanks! /John John Curran President and CEO ARIN From peter.persson at bredband2.se Sat Feb 1 12:48:06 2014 From: peter.persson at bredband2.se (Peter Persson) Date: Sat, 1 Feb 2014 13:48:06 +0100 Subject: Level3 - Las Vegas - issues? In-Reply-To: References: Message-ID: Hey, If you look in mylevel3.net you will be able to see any interruptions in Level3's net. /Peter 2014-01-31 Petter Bruland : > Are there anyone from Level3 here, who can tell me if there are issues with Level3 in Las Vegas area? > > We're hosted out of the Switch SuperNAP, and we're having high packet loss on two different Internet circuits. And at 9:30 AM PST we had no connectivity to all our 70+ remote locations spread all over US on different carriers, from our VPN hub hosted on Level3 > > Any feedback is much appreciated, thanks! > > -Petter > > Petter Bruland | Network Engineer > Allegiant Travel Company > > > > From bedard.phil at gmail.com Sat Feb 1 21:05:15 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 01 Feb 2014 16:05:15 -0500 Subject: Is there such a thing as a 10GBase-T SFP+ transciever In-Reply-To: <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> References: <52EB09B1.3040606@team.dcsi.net.au> <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> Message-ID: That was the reason for the push to the 10x10 MSA by people like Google and other providers who did not want to use MM bundles and didn't want to deal with the expense and power consumption of 100GBase-LR4. LR10 although hasn't really seen much adoption by the vendors, only compatible optics from 3rd party vendors are available now. 40GBase-LR4 QSFP+ aren't really all that expensive these days. Gray market they are less than $2500. Cisco and Arista also just came out with 40G running over a single duplex MM fiber, 100M over OM3, and I expect the other datacenter vendors to follow suit shortly. As for 10GBase-T in a transceiver, I haven't seen that on anyone's roadmap. It will probably come eventually but not for awhile. -Phil On 1/31/14, 7:39 AM, "Eric Clark" wrote: >What I want to see is reasonably priced 40G single mode transceivers. > >I have no idea why 40G and now 100G wasn't rolled out with single mode as >the preference. The argument that "there's a large multimode install >base" doesn't hold water. > >For one thing, you're using enormous amounts of MM fiber to get at best >1/4 of the ports than you previously had. >The best case is that you could get 12 ports where you used to have 48, >but that's messy. >The second issue is cost, if you're running and distance, you've got to >go to OM4, because MM fiber has very limited range at 10G (you're >multiplexing 10G links), and OM4 is insanely expensive. > >Single Mode on the other hand is 'cheap' in comparison. One pair of SM >fiber will handle every speed from 10M to 100G, and over much longer >distances than MM, no matter what grade. > >Unfortunately, since the manufacturers haven't seen fit to push the SM, >the optics are extremely expensive, so we're stuck with 4-12 times the >amount of installed fiber than we really need. > >Grumble. > > >On Jan 30, 2014, at 6:25 PM, Chris Balmain wrote: > >> You may wish to consider twinax for short distance 10G over copper with >>SFP+ at both ends >> >> >>http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Coppe >>r_.2810GSFP.2BCu.29 >> >> Typically marketed as "direct-attach" (you can't remove the cables from >>the transceivers, it's all integrated) >> >> On 31/01/14 12:26, james jones wrote: >>> I would like to know if anyone has seen one of these? If so where? >>>Also if >>> they don't exist why? It would seem to me that it would make it a lot >>> easier to play mix and match with fiber in the DC if they did. Would >>>be so >>> hard to make the 1G SFPs faster (trying to be funny here not arrogant). >>> >>> >>> -James >> > > From jared at puck.nether.net Sat Feb 1 21:18:29 2014 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 1 Feb 2014 16:18:29 -0500 Subject: Is there such a thing as a 10GBase-T SFP+ transciever In-Reply-To: References: <52EB09B1.3040606@team.dcsi.net.au> <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> Message-ID: <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> On Feb 1, 2014, at 4:05 PM, Phil Bedard wrote: > As for 10GBase-T in a transceiver, I haven't seen that on anyone's > roadmap. It will probably come eventually but not for awhile. It must exist, as there is this: http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunderbolt-to-10-gbits-ethernet-desklink-device - Jared From bedard.phil at gmail.com Sat Feb 1 21:30:32 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 01 Feb 2014 16:30:32 -0500 Subject: Is there such a thing as a 10GBase-T SFP+ transciever In-Reply-To: <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> References: <52EB09B1.3040606@team.dcsi.net.au> <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> Message-ID: Pluggable SFP+ transceiver. There are plenty of fixed config 10GBase-T devices out there. Power/space in a SFP+ package just isn't there yet. Phil On 2/1/14, 4:18 PM, "Jared Mauch" wrote: > >On Feb 1, 2014, at 4:05 PM, Phil Bedard wrote: > >> As for 10GBase-T in a transceiver, I haven't seen that on anyone's >> roadmap. It will probably come eventually but not for awhile. > >It must exist, as there is this: > >http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunde >rbolt-to-10-gbits-ethernet-desklink-device > >- Jared From joelja at bogus.com Sat Feb 1 23:30:40 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 01 Feb 2014 15:30:40 -0800 Subject: Is there such a thing as a 10GBase-T SFP+ transciever In-Reply-To: <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> References: <52EB09B1.3040606@team.dcsi.net.au> <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> Message-ID: <52ED83A0.3040400@bogus.com> On 2/1/14, 1:18 PM, Jared Mauch wrote: > > On Feb 1, 2014, at 4:05 PM, Phil Bedard wrote: > >> As for 10GBase-T in a transceiver, I haven't seen that on anyone's >> roadmap. It will probably come eventually but not for awhile. > > It must exist, as there is this: Nah that's a 10G-base-t pci express nic in a box. which is fine and dandy for what it does but the phy doesn't fit in the power envelope or footprint of an sfp+ transciever. > http://store.apple.com/us/product/HC294LL/A/atto-thunderlink-nt1102-thunderbolt-to-10-gbits-ethernet-desklink-device > > - Jared > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From jtowne at slic.com Sun Feb 2 04:03:19 2014 From: jtowne at slic.com (Jonathan Towne) Date: Sat, 1 Feb 2014 23:03:19 -0500 Subject: TWC (AS11351) blocking all NTP? Message-ID: <20140202040319.GD24634@hijacked.us> This evening all of my servers lost NTP sync, stating that our on-site NTP servers hadn't synced in too long. Reference time noted by the local NTP servers: Fri, Jan 31 2014 19:11:29.725 Apparently since then, NTP has been unable to traverse the circuit. Our other provider is shuffling NTP packets just fine, and after finding an NTP peer that return routed in that direction, I was able to get NTP back in shape. Spot checking various NTP peers configured on my end with various looking glasses close to the far-end confirm that anytime the return route is through AS11351, we never get the responses. Outbound routes almost always take the shorter route through our other provider. Is anyone else seeing this, or am I lucky enough to have it localized to my region (Northern NY)? I've created a ticket with the provider, although with it being the weekend, I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk response to the monlist garbage. Still, stopping time without warning is Uncool, Man. -- Jonathan Towne From tmaufer at gmail.com Sun Feb 2 04:21:20 2014 From: tmaufer at gmail.com (Thomas Maufer) Date: Sun, 02 Feb 2014 04:21:20 +0000 Subject: Is there such a thing as a 10GBase-T SFP+ transciever References: <52EB09B1.3040606@team.dcsi.net.au> <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> Message-ID: <5791136147889679268@gmail297201516> IIRC, it takes about 13W to maintain a 10GBASET connection. That's a lot of power to drain from a tiny board that wasn't designed to supply such loads. ~tom On Saturday, February 1, 2014 1:32:58 PM, Phil Bedard wrote: Pluggable SFP+ transceiver. There are plenty of fixed config 10GBase-T devices out there. Power/space in a SFP+ package just isn't there yet. Phil On 2/1/14, 4:18 PM, "Jared Mauch" @ puck.nether.net > wrote: > >On Feb 1, 2014, at 4:05 PM, Phil Bedard @ gmail.com > wrote: > >> As for 10GBase-T in a transceiver, I haven't seen that on anyone's >> roadmap. It will probably come eventually but not for awhile. > >It must exist, as there is this: > >http:// store.apple.com /us/product/HC294LL/A/ atto - thunderlink -nt1102- thunde >rbolt-to-10-gbits-ethernet-desklink-device > >- Jared From nanog at jima.us Sun Feb 2 04:40:29 2014 From: nanog at jima.us (Jima) Date: Sat, 01 Feb 2014 21:40:29 -0700 Subject: Is there such a thing as a 10GBase-T SFP+ transciever In-Reply-To: <52EB09B1.3040606@team.dcsi.net.au> References: <52EB09B1.3040606@team.dcsi.net.au> Message-ID: <52EDCC3D.4010401@jima.us> +1. Cisco calls them Twinax, HP calls them DACs. I don't know what anyone else calls them as it hasn't come up in conversation for me. Cisco appears to offer them in 1, 1.5, 2, 2.5, 3, and 5 meter passive, as well as 7 and 10 meter active. HP has them in 1, 3, 7, 10, and 15 meter; no idea what the passive/active breakdown might be (they don't appear to offer that information as freely). I've mostly used the 3-meter HP DACs so far, and I've been rather happy with them, particularly the cost savings under 2x 10gbit SFP+ fiber transceivers. Jima On 2014-01-30 19:25, Chris Balmain wrote: > You may wish to consider twinax for short distance 10G over copper with > SFP+ at both ends > > http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Copper_.2810GSFP.2BCu.29 > > > Typically marketed as "direct-attach" (you can't remove the cables from > the transceivers, it's all integrated) > > On 31/01/14 12:26, james jones wrote: >> I would like to know if anyone has seen one of these? If so where? >> Also if >> they don't exist why? It would seem to me that it would make it a lot >> easier to play mix and match with fiber in the DC if they did. Would >> be so >> hard to make the 1G SFPs faster (trying to be funny here not arrogant). >> >> >> -James > From seitz at bsd-unix.net Sun Feb 2 05:52:29 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Sun, 2 Feb 2014 00:52:29 -0500 Subject: Is there such a thing as a 10GBase-T SFP+ transciever In-Reply-To: <5791136147889679268@gmail297201516> References: <52EB09B1.3040606@team.dcsi.net.au> <2214438F-F463-48DC-AACA-857497642CCF@gmail.com> <255922FA-E99C-45A1-80D8-51D6FDA33D6F@puck.nether.net> <5791136147889679268@gmail297201516> Message-ID: <20140202055229.GA10520@bsd-unix.net> On Sun, Feb 02, 2014 at 04:21:20AM +0000, Thomas Maufer wrote: > IIRC, it takes about 13W to maintain a 10GBASET connection. That's a lot of > power to drain from a tiny board that wasn't designed to supply such loads. > > ~tom > > On Saturday, February 1, 2014 1:32:58 PM, Phil Bedard > wrote: > > Pluggable SFP+ transceiver. There are plenty of fixed config 10GBase-T > devices out there. Power/space in a SFP+ package just isn't there yet. > > Phil Tom, I believe the newer 10GBase-T standard is between 1.5 and 4W per port depending on the cable length, much better (colder!) than it was. You will also get slightly increased latency with 10GBase-T vs SFP+ -- Bryan G. Seitz From LarrySheldon at cox.net Sun Feb 2 15:30:37 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 02 Feb 2014 09:30:37 -0600 Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: References: <52EB09B1.3040606@team.dcsi.net.au> Message-ID: <52EE649D.5020508@cox.net> On 2/1/2014 10:40 PM, Jima wrote: > +1. Cisco calls them Twinax, HP calls them DACs. I don't know what > anyone else calls them as it hasn't come up in conversation for me. I thought "Twinax" was an IBMish MILSPEC term. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jcurran at istaff.org Sun Feb 2 15:52:05 2014 From: jcurran at istaff.org (John Curran) Date: Sun, 2 Feb 2014 07:52:05 -0800 Subject: Internet Society survey regarding Network Operator involvement with the IETF Message-ID: <06586B12-2FB6-488C-B26B-893B947DCCFE@istaff.org> NANOGers - The folks at the Internet Society are looking for input into how network operators are (or are not) involved in IETF standards development. To that end, they've put together a short survey for network operators on this topic and are asking for help in getting the message out about it. The survey is available here: Some additional background info available here - If you feel so inclined, please complete the survey; it looks to be relatively short/painless. Thanks! /John From fergdawgster at mykolab.com Sun Feb 2 16:14:43 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 02 Feb 2014 08:14:43 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140202040319.GD24634@hijacked.us> References: <20140202040319.GD24634@hijacked.us> Message-ID: <52EE6EF3.7050907@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 While I do not profess to know the cause of your particular NTP sync problem, this *might* be due to knee-jerk reactions to the NTP reflection/amplification DDoS attacks that have been quite an annoyance and operational issue lately. suspect that some operators have found that perhaps they harbored some device inside their own networks are being used (or might be used) to facilitate these attacks: https://www.us-cert.gov/ncas/current-activity/2014/01/10/Network-Time-Protocol-NTP-Amplification-Attacks See also: http://openntpproject.org/ - - ferg On 2/1/2014 8:03 PM, Jonathan Towne wrote: > This evening all of my servers lost NTP sync, stating that our > on-site NTP servers hadn't synced in too long. > > Reference time noted by the local NTP servers: Fri, Jan 31 2014 > 19:11:29.725 > > Apparently since then, NTP has been unable to traverse the circuit. > Our other provider is shuffling NTP packets just fine, and after > finding an NTP peer that return routed in that direction, I was > able to get NTP back in shape. > > Spot checking various NTP peers configured on my end with various > looking glasses close to the far-end confirm that anytime the > return route is through AS11351, we never get the responses. > Outbound routes almost always take the shorter route through our > other provider. > > Is anyone else seeing this, or am I lucky enough to have it > localized to my region (Northern NY)? > > I've created a ticket with the provider, although with it being the > weekend, I have doubts it'll be a quick resolution. I'm sure its a > strange knee-jerk response to the monlist garbage. Still, stopping > time without warning is Uncool, Man. > > -- Jonathan Towne > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLubvMACgkQKJasdVTchbK8mwD9HDHJ2YSDciN8k6YkRDu4MbxS r0zEU/8ofP8HaK8YoEYBANhDP+VIhC3Cz/cKc4TI8WeGHqX1ZWN1OwnxLihR3sjx =KEeR -----END PGP SIGNATURE----- From jtowne at slic.com Sun Feb 2 16:33:13 2014 From: jtowne at slic.com (Jonathan Towne) Date: Sun, 2 Feb 2014 11:33:13 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140202040319.GD24634@hijacked.us> References: <20140202040319.GD24634@hijacked.us> Message-ID: <20140202163313.GF24634@hijacked.us> The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. -- Jonathan Towne On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled: # This evening all of my servers lost NTP sync, stating that our on-site NTP # servers hadn't synced in too long. # # Reference time noted by the local NTP servers: # Fri, Jan 31 2014 19:11:29.725 # # Apparently since then, NTP has been unable to traverse the circuit. Our # other provider is shuffling NTP packets just fine, and after finding an # NTP peer that return routed in that direction, I was able to get NTP back # in shape. # # Spot checking various NTP peers configured on my end with various looking # glasses close to the far-end confirm that anytime the return route is # through AS11351, we never get the responses. Outbound routes almost always # take the shorter route through our other provider. # # Is anyone else seeing this, or am I lucky enough to have it localized to # my region (Northern NY)? # # I've created a ticket with the provider, although with it being the weekend, # I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk # response to the monlist garbage. Still, stopping time without warning is # Uncool, Man. # # -- Jonathan Towne # From alvarezp at alvarezp.ods.org Sun Feb 2 20:05:11 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Sun, 02 Feb 2014 12:05:11 -0800 Subject: Internet Society survey regarding Network Operator involvement with the IETF In-Reply-To: <06586B12-2FB6-488C-B26B-893B947DCCFE@istaff.org> References: <06586B12-2FB6-488C-B26B-893B947DCCFE@istaff.org> Message-ID: <52EEA4F7.2000601@alvarezp.ods.org> On 02/02/2014 07:52 AM, John Curran wrote: > NANOGers - > > The folks at the Internet Society are looking for input into how network operators are (or are not) > involved in IETF standards development. To that end, they've put together a short survey for > network operators on this topic and are asking for help in getting the message out about it. > > The survey is available here: > > Some additional background info available here - > > If you feel so inclined, please complete the survey; it looks to be relatively short/painless. The survey has a problem: the 'Previous' link actually continues on or submits the form. I could not correct a response and the form went on incomplete. I browse without JavaScript so this may be related to the problem. From joelja at bogus.com Sun Feb 2 20:27:58 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 02 Feb 2014 12:27:58 -0800 Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: <52EE649D.5020508@cox.net> References: <52EB09B1.3040606@team.dcsi.net.au> <52EE649D.5020508@cox.net> Message-ID: <52EEAA4E.2030401@bogus.com> On 2/2/14, 7:30 AM, Larry Sheldon wrote: > On 2/1/2014 10:40 PM, Jima wrote: >> +1. Cisco calls them Twinax, HP calls them DACs. I don't know what >> anyone else calls them as it hasn't come up in conversation for me. > > I thought "Twinax" was an IBMish MILSPEC term. twinax could refer to a specific technology or to the presence of dual inner conductors e.g. in contrast to coax or triax. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From johnl at iecc.com Sun Feb 2 20:44:46 2014 From: johnl at iecc.com (John Levine) Date: 2 Feb 2014 20:44:46 -0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140202163313.GF24634@hijacked.us> Message-ID: <20140202204446.50900.qmail@joyce.lan> In article <20140202163313.GF24634 at hijacked.us> you write: >The provider has kindly acknowledged that there is an issue, and are >working on a resolution. Heads up, it may be more than just my region. I'm a Time-Warner cable customer in the Syracuse region, and both of the NTP servers on my home LAN are happily syncing with outside peers. My real servers are hosted in Ithaca, with T-W being one of the upstreams and they're also OK. They were recruited into an NTP DDoS last month (while I was at a meeting working on anti-DDoS best practice, which was a little embarassing) but they're upgraded and locked down now. R's, John From jra at baylink.com Sun Feb 2 20:45:51 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 2 Feb 2014 15:45:51 -0500 (EST) Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: <52EEAA4E.2030401@bogus.com> Message-ID: <11492788.6971.1391373951180.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "joel jaeggli" > > I thought "Twinax" was an IBMish MILSPEC term. > > twinax could refer to a specific technology or to the presence of dual > inner conductors e.g. in contrast to coax or triax. Rather specifically, Twinax refers to cable with 2 center conductors in it's foam or plastic insulator *both within the same shield* -- generally, I think always, a balanced pair. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From contact at nullivex.com Sun Feb 2 21:03:18 2014 From: contact at nullivex.com (Bryan Tong) Date: Sun, 2 Feb 2014 14:03:18 -0700 Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: <11492788.6971.1391373951180.JavaMail.root@benjamin.baylink.com> References: <52EEAA4E.2030401@bogus.com> <11492788.6971.1391373951180.JavaMail.root@benjamin.baylink.com> Message-ID: These cables are most commonly known as "Direct Attach Copper SFP+" On Sunday, February 2, 2014, Jay Ashworth wrote: > ----- Original Message ----- > > From: "joel jaeggli" > > > > > I thought "Twinax" was an IBMish MILSPEC term. > > > > twinax could refer to a specific technology or to the presence of dual > > inner conductors e.g. in contrast to coax or triax. > > Rather specifically, Twinax refers to cable with 2 center conductors in > it's foam or plastic insulator *both within the same shield* -- generally, > I think always, a balanced pair. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > > -- eSited LLC (701) 390-9638 From jeff-kell at utc.edu Sun Feb 2 21:15:55 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 2 Feb 2014 16:15:55 -0500 Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: References: <52EEAA4E.2030401@bogus.com> <11492788.6971.1391373951180.JavaMail.root@benjamin.baylink.com> Message-ID: <52EEB58B.3060107@utc.edu> On 2/2/2014 4:03 PM, Bryan Tong wrote: > These cables are most commonly known as "Direct Attach Copper SFP+" The big issue appears to be that these are not always "consistently functional" crossing vendor lines (sometimes product lines within the same vendor). There does not appear to be any standardization in place. Not sure how much of this is picky vendor software looking for "branded" marks in their transceivers (e.g., Cisco "service unsupported-transceiver") versus true incompatibilities. We have had issues in test cases crossing vendor lines (Cisco / Brocade / Dell / HP) with a "twinax" link that just simply won't work. If anyone has a clear explanation or better understanding, I'm all ears. Personal experience comes from only a few testbed cases. Jeff From cb.list6 at gmail.com Sun Feb 2 22:17:31 2014 From: cb.list6 at gmail.com (Cb B) Date: Sun, 2 Feb 2014 14:17:31 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140202163313.GF24634@hijacked.us> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: On Feb 2, 2014 8:35 AM, "Jonathan Towne" wrote: > > The provider has kindly acknowledged that there is an issue, and are > working on a resolution. Heads up, it may be more than just my region. > And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not "knee jerk", it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. And, i agree bcp38 would help but that was published 14 years ago. CB > -- Jonathan Towne > > > On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled: > # This evening all of my servers lost NTP sync, stating that our on-site NTP > # servers hadn't synced in too long. > # > # Reference time noted by the local NTP servers: > # Fri, Jan 31 2014 19:11:29.725 > # > # Apparently since then, NTP has been unable to traverse the circuit. Our > # other provider is shuffling NTP packets just fine, and after finding an > # NTP peer that return routed in that direction, I was able to get NTP back > # in shape. > # > # Spot checking various NTP peers configured on my end with various looking > # glasses close to the far-end confirm that anytime the return route is > # through AS11351, we never get the responses. Outbound routes almost always > # take the shorter route through our other provider. > # > # Is anyone else seeing this, or am I lucky enough to have it localized to > # my region (Northern NY)? > # > # I've created a ticket with the provider, although with it being the weekend, > # I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk > # response to the monlist garbage. Still, stopping time without warning is > # Uncool, Man. > # > # -- Jonathan Towne > # > From jcurran at istaff.org Sun Feb 2 22:29:48 2014 From: jcurran at istaff.org (John Curran) Date: Sun, 2 Feb 2014 14:29:48 -0800 Subject: Internet Society survey regarding Network Operator involvement with the IETF In-Reply-To: <52EEA4F7.2000601@alvarezp.ods.org> References: <06586B12-2FB6-488C-B26B-893B947DCCFE@istaff.org> <52EEA4F7.2000601@alvarezp.ods.org> Message-ID: <06554E4A-7F8B-4A19-8FDD-81488851AF91@istaff.org> On Feb 2, 2014, at 12:05 PM, Octavio Alvarez wrote: > The survey has a problem: the 'Previous' link actually continues on or > submits the form. I could not correct a response and the form went on > incomplete. I browse without JavaScript so this may be related to the > problem. Good to know; I'll forward along to the some of Internet Society folks so that they are aware of the issue. Thanks! /John From dolson at mcs.anl.gov Sun Feb 2 22:49:23 2014 From: dolson at mcs.anl.gov (Murphy-Olson, Daniel E.) Date: Sun, 2 Feb 2014 22:49:23 +0000 Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: <52EEB58B.3060107@utc.edu> References: <52EEAA4E.2030401@bogus.com> <11492788.6971.1391373951180.JavaMail.root@benjamin.baylink.com> , <52EEB58B.3060107@utc.edu> Message-ID: <2CF3E600DDB3C0418E5BADABFAF66BA32D5387A4@DITKA.anl.gov> Most of the switch vendors have an "official" compatibility list, but I've found that generally the most common compatibility issue is active vs passive twinax. Brocade edge switches and nics are normally active only, which seems to come up a lot - because most short cables are passive unless they are brocade branded. >5m is normally the cutoff for passive twinax. Pretty much everything else I've encountered supports passive. For a while, the intel x520 nics, which are very common, didn't support active connections - but they have since released firmware that fixes this problem. Netapp's lower end gear doesn't support active twinax. ________________________________________ From: Jeff Kell [jeff-kell at utc.edu] Sent: Sunday, February 02, 2014 3:15 PM To: Bryan Tong; Jay Ashworth Cc: NANOG Subject: Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) On 2/2/2014 4:03 PM, Bryan Tong wrote: > These cables are most commonly known as "Direct Attach Copper SFP+" The big issue appears to be that these are not always "consistently functional" crossing vendor lines (sometimes product lines within the same vendor). There does not appear to be any standardization in place. Not sure how much of this is picky vendor software looking for "branded" marks in their transceivers (e.g., Cisco "service unsupported-transceiver") versus true incompatibilities. We have had issues in test cases crossing vendor lines (Cisco / Brocade / Dell / HP) with a "twinax" link that just simply won't work. If anyone has a clear explanation or better understanding, I'm all ears. Personal experience comes from only a few testbed cases. Jeff From mpetach at netflight.com Sun Feb 2 22:49:49 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 2 Feb 2014 14:49:49 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: On Sun, Feb 2, 2014 at 2:17 PM, Cb B wrote: > On Feb 2, 2014 8:35 AM, "Jonathan Towne" wrote: > > > > The provider has kindly acknowledged that there is an issue, and are > > working on a resolution. Heads up, it may be more than just my region. > > > > And not just your provider, everyone is dealing with UDP amp attacks. > > These UDP based amp attacks are off the charts. Wholesale blocking of > traffic at the protocol level to mitigate 10s to 100s of gigs of ddos > traffic is not "knee jerk", it is the right thing to do in a world where > bcp 38 is far from universal and open dns servers, ntp, chargen, and > whatever udp 172 is run wild. > > People who run networks know what it takes to restore service. And > increasingly, that will be clamping ipv4 UDP in the plumbing, both > reactively and proactively. > Please note that it's not that UDP is at fault here; it's applications that are structured to respond to small input packets with large responses. If NTP responded to a single query with a single equivalently sized response, its effectiveness as a DDoS attack would be zero; with zero amplification, the volume of attack traffic would be exactly equivalent to the volume of spoofed traffic the originator could send out in the first place. I agree the source obfuscation aspect of UDP can be annoying, from the spoofing perspective, but that really needs to be recognized to be separate from the volume amplification aspect, which is an application level issue, not a protocol level issue. Thanks! Matt PS--yes, I know it would completely change the dynamics of the internet as we know it today to shift to a 1:1 correspondence between input requests and output replies...but it *would* have a nice side effect of balancing out traffic ratios in many places, altering the settlement landscape in the process. ;) From cb.list6 at gmail.com Sun Feb 2 23:09:55 2014 From: cb.list6 at gmail.com (Cb B) Date: Sun, 2 Feb 2014 15:09:55 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: On Feb 2, 2014 2:54 PM, "Matthew Petach" wrote: > > On Sun, Feb 2, 2014 at 2:17 PM, Cb B wrote: > > > On Feb 2, 2014 8:35 AM, "Jonathan Towne" wrote: > > > > > > The provider has kindly acknowledged that there is an issue, and are > > > working on a resolution. Heads up, it may be more than just my region. > > > > > > > And not just your provider, everyone is dealing with UDP amp attacks. > > > > These UDP based amp attacks are off the charts. Wholesale blocking of > > traffic at the protocol level to mitigate 10s to 100s of gigs of ddos > > traffic is not "knee jerk", it is the right thing to do in a world where > > bcp 38 is far from universal and open dns servers, ntp, chargen, and > > whatever udp 172 is run wild. > > > > People who run networks know what it takes to restore service. And > > increasingly, that will be clamping ipv4 UDP in the plumbing, both > > reactively and proactively. > > > > > Please note that it's not that UDP is at fault here; it's > applications that are structured to respond to small > input packets with large responses. > I dont want to go into fault, there is plenty of that to go around. > If NTP responded to a single query with a single > equivalently sized response, its effectiveness as > a DDoS attack would be zero; with zero amplification, > the volume of attack traffic would be exactly equivalent > to the volume of spoofed traffic the originator could > send out in the first place. > > I agree the source obfuscation aspect of UDP can be > annoying, from the spoofing perspective, but that > really needs to be recognized to be separate from > the volume amplification aspect, which is an application > level issue, not a protocol level issue. > Source obfuscation is not annoying. Combined with amplification, it is the perfect storm for shutting down networks... whereby the only solution is to shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, patches boxes, and so on. My point is: dont expect these abbused services on UDP to last. We have experience in access networks on how to deal with abused protocols. Here is one reference http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ My crystal ball says all of UDP will show up soon. CB > Thanks! > > Matt > PS--yes, I know it would completely change the > dynamics of the internet as we know it today to > shift to a 1:1 correspondence between input > requests and output replies...but it *would* > have a nice side effect of balancing out traffic > ratios in many places, altering the settlement > landscape in the process. ;) From David.Siegel at Level3.com Mon Feb 3 00:25:39 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Mon, 3 Feb 2014 00:25:39 +0000 Subject: Ad Hoc Education Committee Call for Volunteers Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05C0EC550@USIDCWVEMBX10.corp.global.level3.com> Dear NANOG community, In August 2012, Steve Gibbard placed the first call for community volunteers to help establish a NANOG education initiative, which would put together a NANOG-created educational program for junior (and possibly more advanced) network operators. I am happy to report, thanks to the help of those original volunteers, the initial work has proven successful! The Education Series is adopted and an Ad Hoc committee structure has been approved and supported by the NANOG Board. I have agreed to serve as Chair of the Ad Hoc Education Committee and seek volunteers to continue with the committee work. Please consider volunteering your time and effort in support of this NANOG activity. Committee Objectives: * Build a unified branding and message about NANOG's unique position and community * Develop mutually rewarding agreements with instructors and students * Maintain the sense of community and accessibility in class syllabus and instructional materials * Develop and deploy a portfolio of classes that meet the broad range of students. Committee Member Expectations: * Recruit a minimum of 1 instructor per calendar year. * Attend 75% of all scheduled committee calls. * Attend 66% of all NANOG meetings over the course of their two-year term. * Observe two classes over the course of their two-year term. * volunteer up to 10 hours in the 12 weeks leading into a class and an additional 15 hours all year round We are seeking volunteers to fill the following positions: Vice-Chair, Program Director, Instruction Director, and Technical Director, and members at large. If you are interested in participating, please send a short bio to Betty Burke, NANOG Executive Director, betty at nanog.org. Betty can also answer any and all questions you may have. Betty or I will be sure to follow-up with each volunteer and get our important work underway. Sincerely, Dave Siegel From ryangard at gmail.com Mon Feb 3 03:17:34 2014 From: ryangard at gmail.com (ryangard at gmail.com) Date: Mon, 3 Feb 2014 03:17:34 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. Sent on the TELUS Mobility network with BlackBerry -----Original Message----- From: Cb B Date: Sun, 2 Feb 2014 15:09:55 To: Matthew Petach Cc: Subject: Re: TWC (AS11351) blocking all NTP? On Feb 2, 2014 2:54 PM, "Matthew Petach" wrote: > > On Sun, Feb 2, 2014 at 2:17 PM, Cb B wrote: > > > On Feb 2, 2014 8:35 AM, "Jonathan Towne" wrote: > > > > > > The provider has kindly acknowledged that there is an issue, and are > > > working on a resolution. Heads up, it may be more than just my region. > > > > > > > And not just your provider, everyone is dealing with UDP amp attacks. > > > > These UDP based amp attacks are off the charts. Wholesale blocking of > > traffic at the protocol level to mitigate 10s to 100s of gigs of ddos > > traffic is not "knee jerk", it is the right thing to do in a world where > > bcp 38 is far from universal and open dns servers, ntp, chargen, and > > whatever udp 172 is run wild. > > > > People who run networks know what it takes to restore service. And > > increasingly, that will be clamping ipv4 UDP in the plumbing, both > > reactively and proactively. > > > > > Please note that it's not that UDP is at fault here; it's > applications that are structured to respond to small > input packets with large responses. > I dont want to go into fault, there is plenty of that to go around. > If NTP responded to a single query with a single > equivalently sized response, its effectiveness as > a DDoS attack would be zero; with zero amplification, > the volume of attack traffic would be exactly equivalent > to the volume of spoofed traffic the originator could > send out in the first place. > > I agree the source obfuscation aspect of UDP can be > annoying, from the spoofing perspective, but that > really needs to be recognized to be separate from > the volume amplification aspect, which is an application > level issue, not a protocol level issue. > Source obfuscation is not annoying. Combined with amplification, it is the perfect storm for shutting down networks... whereby the only solution is to shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, patches boxes, and so on. My point is: dont expect these abbused services on UDP to last. We have experience in access networks on how to deal with abused protocols. Here is one reference http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ My crystal ball says all of UDP will show up soon. CB > Thanks! > > Matt > PS--yes, I know it would completely change the > dynamics of the internet as we know it today to > shift to a 1:1 correspondence between input > requests and output replies...but it *would* > have a nice side effect of balancing out traffic > ratios in many places, altering the settlement > landscape in the process. ;) From mark.tinka at seacom.mu Mon Feb 3 03:21:06 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 3 Feb 2014 05:21:06 +0200 Subject: Updated ARIN allocation information In-Reply-To: <20140130235858.3ADEAE14FF7@rock.dv.isc.org> References: <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> Message-ID: <201402030521.10052.mark.tinka@seacom.mu> On Friday, January 31, 2014 01:58:58 AM Mark Andrews wrote: > This range adds a maximum of 245760 (2^18-2^14) routes to > the global routing table. Do you really want to go to > court for this many routes? There is also a reasonable chance that acceptance of /28's could be strict in the beginning. But at some point, I imagine some operators (either due to lack of clue or just laziness) will simply write "everything else up to /28", and then routers on the Internet will start to pick up a lot of the gunk that "up to /24" filters have been keeping at bay. Prefixes longer than /24 (or /48) are especially common at exchange points, either by mistake or design. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From LarrySheldon at cox.net Mon Feb 3 03:38:36 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 02 Feb 2014 21:38:36 -0600 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: <52EF0F3C.1050001@cox.net> On 2/2/2014 9:17 PM, ryangard at gmail.com wrote: > I'd hate to think that NetOps would be so heavy handed in blocking > all of UDP, as this would essentially halt quite a bit of audio/video > traffic. That being said, there's still quite the need for protocol > improvement when making use of UDP, but blocking UDP as a whole is > definitely not a resolution, and simply creating a wall that not only > keeps the abusive traffic out, but keeps legitimate traffic from > flowing freely as it should. "We had to burn down the village to save it." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From cb.list6 at gmail.com Mon Feb 3 03:45:10 2014 From: cb.list6 at gmail.com (Cb B) Date: Sun, 2 Feb 2014 19:45:10 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52EF0F3C.1050001@cox.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: On Feb 2, 2014 7:41 PM, "Larry Sheldon" wrote: > > On 2/2/2014 9:17 PM, ryangard at gmail.com wrote: >> >> I'd hate to think that NetOps would be so heavy handed in blocking >> all of UDP, as this would essentially halt quite a bit of audio/video >> traffic. That being said, there's still quite the need for protocol >> improvement when making use of UDP, but blocking UDP as a whole is >> definitely not a resolution, and simply creating a wall that not only >> keeps the abusive traffic out, but keeps legitimate traffic from >> flowing freely as it should. > > > "We had to burn down the village to save it." > > Close. More like a hurricane is landing in NYC so we are forcing an evacuation. But. Your network, your call. CB > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From geraint at koding.com Mon Feb 3 03:49:37 2014 From: geraint at koding.com (Geraint Jones) Date: Mon, 03 Feb 2014 16:49:37 +1300 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Message-ID: On 3/02/14 4:45 pm, "Cb B" wrote: >On Feb 2, 2014 7:41 PM, "Larry Sheldon" wrote: >> >> On 2/2/2014 9:17 PM, ryangard at gmail.com wrote: >>> >>> I'd hate to think that NetOps would be so heavy handed in blocking >>> all of UDP, as this would essentially halt quite a bit of audio/video >>> traffic. That being said, there's still quite the need for protocol >>> improvement when making use of UDP, but blocking UDP as a whole is >>> definitely not a resolution, and simply creating a wall that not only >>> keeps the abusive traffic out, but keeps legitimate traffic from >>> flowing freely as it should. >> >> >> "We had to burn down the village to save it." >> >> > >Close. More like a hurricane is landing in NYC so we are forcing an >evacuation. > >But. Your network, your call. > >CB We block all outbound UDP for our ~200,000 Users for this very reason (with the exception of some whitelisted NTP and DNS servers). So far we have had 0 complaints, and 0 UDP floods sourced from us -- Geraint Jones Director of Systems & Infrastructure Koding AS62805 (We are hiring) https://koding.com geraint at koding.com Phone (415) 653-0083 > >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >> From rdobbins at arbor.net Mon Feb 3 03:58:29 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 03:58:29 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: Message-ID: <796DB246-58DA-4538-9E67-471D5793E914@arbor.net> On Feb 3, 2014, at 10:49 AM, Geraint Jones wrote: > We block all outbound UDP for our ~200,000 Users for this very reason Actually, you could've (and should've) been far more selective in what you filtered via ACLs, IMHO. What about your users who play online games like BF4? I'm a big believer in using ACLs to intelligently preclude reflection/amplification abuse, but wholesale filtering of all UDP takes matters too far, IMHO. My suggestion would be to implement antispoofing on the southward interfaces of the customer aggregation edge (if you can't implement it via mechanisms such as cable ip source verify even further southward), and then implement a default ingress ACL on the coreward interfaces of the customer aggregation gateways to block inbound UDP destined to ntp, chargen, DNS, and SNMP ports only. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From brian at aereo.com Mon Feb 3 04:04:51 2014 From: brian at aereo.com (Brian Loveland) Date: Sun, 2 Feb 2014 23:04:51 -0500 Subject: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) In-Reply-To: <2CF3E600DDB3C0418E5BADABFAF66BA32D5387A4@DITKA.anl.gov> References: <52EEAA4E.2030401@bogus.com> <11492788.6971.1391373951180.JavaMail.root@benjamin.baylink.com> <52EEB58B.3060107@utc.edu> <2CF3E600DDB3C0418E5BADABFAF66BA32D5387A4@DITKA.anl.gov> Message-ID: We've worked through the same issues with Brocade/Intel, although we found that even though Brocade specs active only, our ICX switches don't reject passive cables, although oddly the Intel branded passive cables show up as UNSUPPORTED (but FCI and Molex ones from Digikey show up as the correct length and correct type of cable). If you do decide to go generic make sure you check the sizing. Maybe Brocade SFP+ drive is weak but using some 28 AWG 5M cables we've seen it takes a lot of errors. Switching to 26 AWG or 24 AWG solved the issue. I suspect Brocade requires active just from their storage background. On Sun, Feb 2, 2014 at 5:49 PM, Murphy-Olson, Daniel E. wrote: > Most of the switch vendors have an "official" compatibility list, but I've > found that generally the most common compatibility issue is active vs > passive twinax. > > Brocade edge switches and nics are normally active only, which seems to > come up a lot - because most short cables are passive unless they are > brocade branded. >5m is normally the cutoff for passive twinax. Pretty > much everything else I've encountered supports passive. > > For a while, the intel x520 nics, which are very common, didn't support > active connections - but they have since released firmware that fixes this > problem. > Netapp's lower end gear doesn't support active twinax. > > > ________________________________________ > From: Jeff Kell [jeff-kell at utc.edu] > Sent: Sunday, February 02, 2014 3:15 PM > To: Bryan Tong; Jay Ashworth > Cc: NANOG > Subject: Re: Twinax trivia check (was Re: Is there such a thing as a > 10GBase-T SFP+ transciever) > > On 2/2/2014 4:03 PM, Bryan Tong wrote: > > These cables are most commonly known as "Direct Attach Copper SFP+" > > The big issue appears to be that these are not always "consistently > functional" crossing vendor lines (sometimes product lines within the > same vendor). There does not appear to be any standardization in > place. Not sure how much of this is picky vendor software looking for > "branded" marks in their transceivers (e.g., Cisco "service > unsupported-transceiver") versus true incompatibilities. > > We have had issues in test cases crossing vendor lines (Cisco / Brocade > / Dell / HP) with a "twinax" link that just simply won't work. If > anyone has a clear explanation or better understanding, I'm all ears. > Personal experience comes from only a few testbed cases. > > Jeff > > > > From rdobbins at arbor.net Mon Feb 3 04:09:39 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 04:09:39 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <796DB246-58DA-4538-9E67-471D5793E914@arbor.net> References: <796DB246-58DA-4538-9E67-471D5793E914@arbor.net> Message-ID: <60E1807A-CB88-41EC-8F98-567ED0C96C00@arbor.net> On Feb 3, 2014, at 10:58 AM, Dobbins, Roland wrote: > I'm a big believer in using ACLs to intelligently preclude reflection/amplification abuse, but wholesale filtering of all UDP takes matters too far, IMHO. I also think that restricting your users by default to your own recursive DNS servers, plus a couple of well-known, well-run public recursive services, is a good idea - as long as you allow your users to opt out. This has nothing to do with DDoS, but with other types of issues. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nanog at deman.com Mon Feb 3 05:45:50 2014 From: nanog at deman.com (Michael DeMan) Date: Sun, 2 Feb 2014 21:45:50 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140202204446.50900.qmail@joyce.lan> References: <20140202204446.50900.qmail@joyce.lan> Message-ID: The recently publicized mechanism to leverage NTP servers for amplified DoS attacks is seriously effective. I had a friend who had a local ISP affected by this Thursday and also another case where just two asterisk servers saturated a 100mbps link to the point of unusability. Once more - this exploit is seriously effective at using bandwidth by reflection. From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than allow it to continue and cause disruptions elsewhere. - Mike On Feb 2, 2014, at 12:44 PM, John Levine wrote: > In article <20140202163313.GF24634 at hijacked.us> you write: >> The provider has kindly acknowledged that there is an issue, and are >> working on a resolution. Heads up, it may be more than just my region. > > I'm a Time-Warner cable customer in the Syracuse region, and both of > the NTP servers on my home LAN are happily syncing with outside peers. > > My real servers are hosted in Ithaca, with T-W being one of the > upstreams and they're also OK. They were recruited into an NTP DDoS > last month (while I was at a meeting working on anti-DDoS best > practice, which was a little embarassing) but they're upgraded and > locked down now. > > R's, > John > > > From rdobbins at arbor.net Mon Feb 3 06:02:18 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 06:02:18 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202204446.50900.qmail@joyce.lan> Message-ID: <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> On Feb 3, 2014, at 12:45 PM, Michael DeMan wrote: > From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than allow it to continue and cause disruptions elsewhere. Per my previous post in this thread, there are ways to do this without blocking client access to ntp servers; in point of fact, unless the ISP in question isn't performing antispoofing at their customer aggregation edge, blocking client access to ntp servers does nothing to address (pardon the pun) the issue of ntp reflection/amplification DDoS attacks. All that broadband access operators need to do is to a) enforce antispoofing as close to their customers as possible, and b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge (same for DNS, chargen, and SNMP). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Feb 3 06:16:23 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 06:16:23 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> References: <20140202204446.50900.qmail@joyce.lan> <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> Message-ID: <191434F9-73EE-4F4C-8A3D-9305B59C9C12@arbor.net> On Feb 3, 2014, at 1:02 PM, Dobbins, Roland wrote: > b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge Actually, this can cause problems for ntpds operating in symmetric mode, where both the source and destination ports are UDP/123. Allowing inbound UDP/123 - UDP/123 and then rate-limiting it would be one approach; another would be to block outbound UDP/123 emanating from customers based upon packet size, if one's hardware allows matching on size in ACLs. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nanog at deman.com Mon Feb 3 06:54:59 2014 From: nanog at deman.com (Michael DeMan) Date: Sun, 2 Feb 2014 22:54:59 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> References: <20140202204446.50900.qmail@joyce.lan> <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> Message-ID: On Feb 2, 2014, at 10:02 PM, Dobbins, Roland wrote: > > On Feb 3, 2014, at 12:45 PM, Michael DeMan wrote: > >> From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than allow it to continue and cause disruptions elsewhere. > > Per my previous post in this thread, there are ways to do this without blocking client access to ntp servers; in point of fact, unless the ISP in question isn't performing antispoofing at their customer aggregation edge, blocking client access to ntp servers does nothing to address (pardon the pun) the issue of ntp reflection/amplification DDoS attacks. Agreed, and I was not trying to get into arguments about saying whether 'blocking' is appropriate or not. I was simply suggesting that a provider, if they found themselves in a position where this was causing lots of troubles and impacting things in a large, might have had taken a 'broad brush' approach to stabilize things while they work on a more proper solution. > > All that broadband access operators need to do is to a) enforce antispoofing as close to their customers as possible, and b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge (same for DNS, chargen, and SNMP). I certainly would not want to provide as part the AUP (as seller or buyer), a policy that fundamentals like NTP are 'blocked' to customers. Seems like too much of a slippery slope for my taste. In regards to anti-spoofing measures - I think there a couple of vectors about the latest NTP attack where more rigorous client-side anti-spoofing could help but will not solve it overall. Trying to be fair and practical (from my perspective) - it is a lot easier and quicker to patch/workaround IPv4 problems and address proper solutions via IPv6 and associated RFCs? - Michael DeMan > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From rdobbins at arbor.net Mon Feb 3 07:08:25 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 07:08:25 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202204446.50900.qmail@joyce.lan> <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> Message-ID: <36E69809-C0B7-497D-A4AA-B251D0C9EA4A@arbor.net> On Feb 3, 2014, at 1:54 PM, Michael DeMan wrote: > I certainly would not want to provide as part the AUP (as seller or buyer), a policy that fundamentals like NTP are 'blocked' to customers. Seems like too much of a slippery slope for my taste. The idea is to block traffic to misconfigured ntpds on broadband customer access networks, not to limit their choice of which ntp servers to use. > In regards to anti-spoofing measures - I think there a couple of vectors about the latest NTP attack where more rigorous client-side anti-spoofing could help but will not solve it overall. Rigorous antispoofing would solve the problem of all reflection/amplification DDoS attacks. My hunch is that most spoofed traffic involved in these attacks actually emanates from compromised/abused servers on IDC networks (including so-called 'bulletproof' miscreant-friendly networks), but I've no data to support that, yet. > Trying to be fair and practical (from my perspective) - it is a lot easier and quicker to patch/workaround IPv4 problems and address proper solutions via IPv6 and associated RFCs? There's nothing in IPv6 which makes any difference. The ultimate solution is antispoofing at the customer edge. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Feb 3 07:22:19 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 07:22:19 +0000 Subject: BCP38.info In-Reply-To: <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> Message-ID: <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> On Jan 29, 2014, at 3:03 AM, Jared Mauch wrote: > Sure, but this means that network is allowing the spoofing :) > > What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested. This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Feb 3 07:50:11 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 07:50:11 +0000 Subject: BCP38.info In-Reply-To: <2232e78b$617bc9ca$169fef59$@flhsi.com> References: <2232e78b$617bc9ca$169fef59$@flhsi.com> Message-ID: <142A08A8-DBA7-4589-B9CF-60A029DFF055@arbor.net> On Jan 29, 2014, at 4:47 AM, Nick Olsen wrote: > After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was > "Spoofed". Forgive me for being slow, but doesn't this seem to imply that there isn't any antispoofing taking place at the GRE tunnel ingress? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Feb 3 07:55:53 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 07:55:53 +0000 Subject: BCP38.info In-Reply-To: <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> Message-ID: <2C239767-46EF-4A42-8586-A57A60E5D0E1@arbor.net> On Feb 3, 2014, at 2:22 PM, Dobbins, Roland wrote: > This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing. It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . . ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Feb 3 08:07:06 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 08:07:06 +0000 Subject: BCP38.info In-Reply-To: <2C239767-46EF-4A42-8586-A57A60E5D0E1@arbor.net> References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> <2C239767-46EF-4A42-8586-A57A60E5D0E1@arbor.net> Message-ID: <794951B3-F26E-493F-8CD6-404202813B9D@arbor.net> On Feb 3, 2014, at 2:55 PM, Dobbins, Roland wrote: > It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . . Another question is whether or not it's possible that in at least some cases, MITMing boxes on intermediary networks are grabbing these queries and then spoofing the scanner source IP as they redirect the queries . . . . if this is taking place, then it would be the network(s) with the MITMing box(es) which allow spoofing, irrespective of whether or not the intended destination networks do, yes? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nanog at deman.com Mon Feb 3 08:24:08 2014 From: nanog at deman.com (Michael DeMan) Date: Mon, 3 Feb 2014 00:24:08 -0800 Subject: BCP38.info, RELATING: TWC (AS11351) blocking all NTP? In-Reply-To: <794951B3-F26E-493F-8CD6-404202813B9D@arbor.net> References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> <2C239767-46EF-4A42-8586-A57A60E5D0E1@arbor.net> <794951B3-F26E-493F-8CD6-404202813B9D@arbor.net> Message-ID: Hi, I think I might have already deleted subject matter a few days ago in re: BCP38. What exactly are you trying to do? I agree my general comment about the recent NTP weaknesses should be addressed via IPv6 RFC may have been mis-understood. I meant mostly that with IPv6 NAT goes away, all devices are exposed, and we also have the 'internet of things' - much more subject to potential abuse. An NTPv5 solution that could be done with NTP services already, and would be more of a 'best practices of how this shit starts up and what it can do' and educating vendors to have reasonable behavior in the first place? And an NTPv6 solution/RFC/guideline that was similar, could help? Neither will 'solve the problem' - but I think the idea of managing what somebody can do and having the provider filter in/out on IPv4 and/or mobile ipV4, much less ipV6 is very unorthodox and much against the spirit of having global m:n communications be helpful for humanity. My apologies if I mis-understand your recent and last few e-mails. I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol to 'protect the end user' is the wrong way to go when compared to just having things work in a secure manner. - Mike On Feb 3, 2014, at 12:07 AM, Dobbins, Roland wrote: > > On Feb 3, 2014, at 2:55 PM, Dobbins, Roland wrote: > >> It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . . > > Another question is whether or not it's possible that in at least some cases, MITMing boxes on intermediary networks are grabbing these queries and then spoofing the scanner source IP as they redirect the queries . . . . if this is taking place, then it would be the network(s) with the MITMing box(es) which allow spoofing, irrespective of whether or not the intended destination networks do, yes? > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From rdobbins at arbor.net Mon Feb 3 08:32:15 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 08:32:15 +0000 Subject: BCP38.info, RELATING: TWC (AS11351) blocking all NTP? In-Reply-To: References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> <2C239767-46EF-4A42-8586-A57A60E5D0E1@arbor.net> <794951B3-F26E-493F-8CD6-404202813B9D@arbor.net> Message-ID: <83712B7D-5022-49B8-BCC3-12C0BDD5F129@arbor.net> On Feb 3, 2014, at 3:24 PM, Michael DeMan wrote: > I meant mostly that with IPv6 NAT goes away, I don't know if this is true or not - and even if it is true, it's going to be a long, long time before the IPv4 Internet goes away (like, maybe, pretty much forever, heh). > An NTPv5 solution that could be done with NTP services already, and would be more of a 'best practices of how this shit starts up and what it can do' and educating vendors to have reasonable behavior in the first place? Yes, but that's many years away, and doesn't address legacy issues. > And an NTPv6 solution/RFC/guideline that was similar, could help? Again, many years away, and doesn't address legacy issues. > I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol to 'protect the end user' is the wrong way to go when compared to just having things work in a secure manner. Yes, but since the latter part of this statement is unattainable in the foreseeable future, the idea is actually to protect *the rest of the Internet* from misconfigured CPE. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bortzmeyer at nic.fr Mon Feb 3 09:52:29 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 3 Feb 2014 10:52:29 +0100 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: <20140203095228.GA28941@nic.fr> On Sun, Feb 02, 2014 at 02:49:49PM -0800, Matthew Petach wrote a message of 49 lines which said: > If NTP responded to a single query with a single equivalently sized > response, its effectiveness as a DDoS attack would be zero; with > zero amplification, the volume of attack traffic would be exactly > equivalent to the volume of spoofed traffic the originator could > send out in the first place. It is a bit more complicated. Reflection with amplification is certainly much less useful for an attacker but it has still some advantages: the attack traffic coming to the victim's AS will be distributed differently (entering via different peers), making tracking the attacker through Netflow/Ipfix more difficult. From bortzmeyer at nic.fr Mon Feb 3 09:55:00 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 3 Feb 2014 10:55:00 +0100 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <60E1807A-CB88-41EC-8F98-567ED0C96C00@arbor.net> References: <796DB246-58DA-4538-9E67-471D5793E914@arbor.net> <60E1807A-CB88-41EC-8F98-567ED0C96C00@arbor.net> Message-ID: <20140203095500.GB28941@nic.fr> On Mon, Feb 03, 2014 at 04:09:39AM +0000, Dobbins, Roland wrote a message of 20 lines which said: > I also think that restricting your users by default to your own > recursive DNS servers, plus a couple of well-known, well-run public > recursive services, is a good idea - as long as you allow your users > to opt out. That's a big "as long". I agree with you but I'm fairly certain that most ISP who deny their users the ability to do DNS requests directly (or to run their own DNS resolver) have no such opt-out (or they make it expensive and/or complicated). After all, when outside DNS is blocked, it is more often for business reasons (forcing the users to use a local lying resolver, with ads when NXDOMAIN is returned) than for security reasons. From rdobbins at arbor.net Mon Feb 3 11:16:30 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 11:16:30 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140203095500.GB28941@nic.fr> References: <796DB246-58DA-4538-9E67-471D5793E914@arbor.net> <60E1807A-CB88-41EC-8F98-567ED0C96C00@arbor.net> <20140203095500.GB28941@nic.fr> Message-ID: On Feb 3, 2014, at 4:55 PM, Stephane Bortzmeyer wrote: > I agree with you but I'm fairly certain that most ISP who deny their users the ability to do DNS requests directly > (or to run their own DNS resolver) have no such opt-out (or they make it expensive and/or complicated). There are some who do it, though, with a user-friendly portal - I've seen it in action. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From Valdis.Kletnieks at vt.edu Mon Feb 3 11:34:54 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Feb 2014 06:34:54 -0500 Subject: BCP38.info, RELATING: TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "Mon, 03 Feb 2014 00:24:08 -0800." References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> <1F562C84-3345-46BD-BABB-2AC19356C806@arbor.net> <2C239767-46EF-4A42-8586-A57A60E5D0E1@arbor.net> <794951B3-F26E-493F-8CD6-404202813B9D@arbor.net> Message-ID: <151085.1391427294@turing-police.cc.vt.edu> On Mon, 03 Feb 2014 00:24:08 -0800, Michael DeMan said: > An NTPv5 solution that could be done with NTP services already Doesn't matter - the same people that aren't upgrading to a correctly configured NTPv4 aren't going to upgrade to an NTPv5. No need at all for a protocol increment (and actually doing that has its own issues). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tglassey at earthlink.net Mon Feb 3 14:14:30 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Mon, 03 Feb 2014 06:14:30 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> Message-ID: <52EFA446.303@earthlink.net> How about this - I have proposed to NIST we start filtering - realize that the NIST ITS program itself was setup to run NTP in an open access mode - we host a dozen or so of those systems and so we get hit all the time. The solution is actually not running timing services across UDP because of the hand shaking over the open Internet - and that obviously isnt going to happen. My suggestion is that for those that need access we set up VLAN trunked private networking models to your ISP MPOE as it were in a digital context. If this interests you contact me off list. Todd Glassey - USTiming.ORG On 2/2/2014 7:17 PM, ryangard at gmail.com wrote: > I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. > Sent on the TELUS Mobility network with BlackBerry > > -----Original Message----- > From: Cb B > Date: Sun, 2 Feb 2014 15:09:55 > To: Matthew Petach > Cc: > Subject: Re: TWC (AS11351) blocking all NTP? > > On Feb 2, 2014 2:54 PM, "Matthew Petach" wrote: >> On Sun, Feb 2, 2014 at 2:17 PM, Cb B wrote: >> >>> On Feb 2, 2014 8:35 AM, "Jonathan Towne" wrote: >>>> The provider has kindly acknowledged that there is an issue, and are >>>> working on a resolution. Heads up, it may be more than just my > region. >>> And not just your provider, everyone is dealing with UDP amp attacks. >>> >>> These UDP based amp attacks are off the charts. Wholesale blocking of >>> traffic at the protocol level to mitigate 10s to 100s of gigs of ddos >>> traffic is not "knee jerk", it is the right thing to do in a world where >>> bcp 38 is far from universal and open dns servers, ntp, chargen, and >>> whatever udp 172 is run wild. >>> >>> People who run networks know what it takes to restore service. And >>> increasingly, that will be clamping ipv4 UDP in the plumbing, both >>> reactively and proactively. >>> >> >> Please note that it's not that UDP is at fault here; it's >> applications that are structured to respond to small >> input packets with large responses. >> > I dont want to go into fault, there is plenty of that to go around. > >> If NTP responded to a single query with a single >> equivalently sized response, its effectiveness as >> a DDoS attack would be zero; with zero amplification, >> the volume of attack traffic would be exactly equivalent >> to the volume of spoofed traffic the originator could >> send out in the first place. >> >> I agree the source obfuscation aspect of UDP can be >> annoying, from the spoofing perspective, but that >> really needs to be recognized to be separate from >> the volume amplification aspect, which is an application >> level issue, not a protocol level issue. >> > Source obfuscation is not annoying. Combined with amplification, it is the > perfect storm for shutting down networks... whereby the only solution is to > shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, > patches boxes, and so on. > > My point is: dont expect these abbused services on UDP to last. We have > experience in access networks on how to deal with abused protocols. Here is > one reference > > http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ > > My crystal ball says all of UDP will show up soon. > > CB > >> Thanks! >> >> Matt >> PS--yes, I know it would completely change the >> dynamics of the internet as we know it today to >> shift to a 1:1 correspondence between input >> requests and output replies...but it *would* >> have a nice side effect of balancing out traffic >> ratios in many places, altering the settlement >> landscape in the process. ;) -- ------------- Personal Email - Disclaimers Apply From Valdis.Kletnieks at vt.edu Mon Feb 3 14:34:05 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Feb 2014 09:34:05 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "Mon, 03 Feb 2014 06:14:30 -0800." <52EFA446.303@earthlink.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> Message-ID: <163127.1391438045@turing-police.cc.vt.edu> On Mon, 03 Feb 2014 06:14:30 -0800, TGLASSEY said: > My suggestion is that for those that need access we set up VLAN trunked > private networking models to your ISP MPOE as it were in a digital context. That's going to be one big VLAN. /me makes popcorn. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tglassey at earthlink.net Mon Feb 3 14:50:56 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Mon, 03 Feb 2014 06:50:56 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <163127.1391438045@turing-police.cc.vt.edu> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> <163127.1391438045@turing-police.cc.vt.edu> Message-ID: <52EFACD0.9000507@earthlink.net> Or a whole bunch of small ones Vladis - and yes we are capable of handling the loads. :-) Todd On 2/3/2014 6:34 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 03 Feb 2014 06:14:30 -0800, TGLASSEY said: > >> My suggestion is that for those that need access we set up VLAN trunked >> private networking models to your ISP MPOE as it were in a digital context. > That's going to be one big VLAN. > > /me makes popcorn. -- ------------- Personal Email - Disclaimers Apply From Valdis.Kletnieks at vt.edu Mon Feb 3 15:01:13 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Feb 2014 10:01:13 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "Mon, 03 Feb 2014 06:50:56 -0800." <52EFACD0.9000507@earthlink.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> <163127.1391438045@turing-police.cc.vt.edu> <52EFACD0.9000507@earthlink.net> Message-ID: <165658.1391439673@turing-police.cc.vt.edu> On Mon, 03 Feb 2014 06:50:56 -0800, TGLASSEY said: > Or a whole bunch of small ones Vladis - and yes we are capable of > handling the loads. 38,917 vlans later... /me makes even *more* popcorn... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Jason_Livingood at cable.comcast.com Mon Feb 3 15:07:56 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 3 Feb 2014 15:07:56 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> Message-ID: On 2/3/14, 1:02 AM, "Dobbins, Roland" wrote: >All that broadband access operators need to do is to a) enforce >antispoofing as close to their customers as possible, Many probably do so already. But as well all know, it only takes a few that don?t to create a large scale issue. IMHO if we want to change this we need to (1) measure where and how anti-spoofing is not implemented, (2) contact networks that have not implemented with recommendations on how to do so (a la bcp38.info), and (3) failing reasonable response to #2 to start a public running list of networks that have inadequate levels of anti-spoofing (according to some reasonable standard, and probably more nuanced than a binary result). Jason From ammar.alsalih at gmail.com Mon Feb 3 13:33:34 2014 From: ammar.alsalih at gmail.com (Ammar Salih) Date: Mon, 3 Feb 2014 16:33:34 +0300 Subject: Do network diagnostic tools need upgrade? Message-ID: Hello NANOG list members, I have a question for you, are you happy with the current network diagnostic tools, like ping, trace route .. etc, don't you think it's time to have an upgraded version of icmp protocol? from my side there is a lot that I can NOT do with current tools and protocols, here are few scenarios, and I would like to hear yours: First scenario: To be able to troubleshoot advanced networks with complex QoS and policy-based routing configuration, where ping, traceroute and other network diagnostic tools do not provide accurate readings, for example, you are troubleshooting a web server with ping, and it looks functioning quite well (packet loss and round trip time is all good), but web services are still significantly slow, the fact is icmp and tcp:80 might have different priorities and bandwidth limits on each router along the path between the client and the server, in this case, network admins usually use telnet applications like (Paping), well it may help if the forward and return path of all packets are exactly the same. Second scenario: So another possible scenario is that you need to determine readings for forward and return paths, TraceRoute for example gives you forward path only using icmp. But what if you need to troubleshoot a VoIP server for example, assuming that packets return path might not be the same as forward path. Third scenario: One of the most common problems in networking, is that you don't have access to all equipment between client and server, but you have to troubleshoot the path between them and to understand where the problem exactly is in order to contact the right person without having the privilege to check the configuration on each router. Fourth scenario: Also, with trace route you can't determine the actual path, for example, the router may direct http traffic to proxy server while leaving other traffic going through a different hop. From leo.vegoda at icann.org Mon Feb 3 17:17:46 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 3 Feb 2014 09:17:46 -0800 Subject: Updated ARIN allocation information In-Reply-To: <52EC3594.8080304@fud.no> References: <52E97DCB.5090803@rollernet.us> <20140130051711.986ACE0C64B@rock.dv.isc.org> <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net> <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us> <20140131002654.2020FE16752@rock.dv.isc.org> <20140131032004.1CD49E1E601@rock.dv.isc.org> <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org> <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19684A1224B@EXVPMBX100-1.exc.icann.org> Tore Anderson wrote: [...] > It's not exactly new. Like I've mentioned earlier in this thread, the > RIPE NCC has granted assignments smaller than /24 to requestors since, > well, "forever". There are currently 238 such assignments listed in > delegated-ripencc-extended-latest.txt. However, these microscopic > assignments have proven hugely unpopular, amounting for only a fraction > of a percent of the total (there are 27733 assignments equal to or > larger than /24 in the same file). If I remember correctly, while some (most?) people were disappointed by the lack of a minimum size for PI assignments, others valued the ability to register addresses for interfaces that needed to be unique but did not require global connectivity. Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From tore at fud.no Mon Feb 3 17:38:17 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 03 Feb 2014 18:38:17 +0100 Subject: BGP multihoming In-Reply-To: <52E96DF6.1@fud.no> References: <52E96DF6.1@fud.no> Message-ID: <52EFD409.6090100@fud.no> * Tore Anderson > * Baldur Norddahl > >> Is assigning a /24 from my own PA space for the purpose of BGP >> multihoming considered sufficient "need"? > > Not with current policies, no That was then. With current policies: yes. To elaborate a bit, the RIPE Community just reached consensus on a policy change that makes the size and the purpose of an assignment entirely a local decision. That means that if you and your customer agree that a /X is needed for purpose Y, and you as the LIR have the available space and the willingness to make that assignment, you are now free to make it. The new IPV4 policy does not mandate any limits to what X and Y might be, except for the fact that Y must somehow involve ?operating a network? (your use case certainly qualifies). Tore From dmburgess at linktechs.net Mon Feb 3 17:48:04 2014 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 3 Feb 2014 11:48:04 -0600 Subject: BGP peer traffic monitoring Message-ID: <50710E9A7E64454C974049FC998EB655018DE82C@03-exchange.lti.local> I have a router with about 20 peers, most are all on a single port (local exchange), how is everyone monitoring traffic to individual peers? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From peter.phaal at gmail.com Mon Feb 3 17:42:57 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 3 Feb 2014 09:42:57 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52EF0F3C.1050001@cox.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: Why burn the village when only one house is the problem? I thought there might be some interest in hearing about work being done to use SDN to automatically configure filtering in existing switches and routers to mitigate flood attacks. Real-time analytics based on measurements from switches/routers (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the switches/routers to selectively filter traffic based on UDP port and IP source / destination. By deploying a DDoS mitigation SDN application, providers can use their existing infrastructure to protect their own and their customers networks from flood attacks, and generate additional revenue by delivering flood protection as a value added service. https://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case/ http://events.linuxfoundation.org/sites/events/files/slides/flow-aware-real-time-sdn-analytics-odl-summit-v2.pdf Specifically looking at sFlow, large flood attacks can be detected within a second. The following article describes a simple example using integrated hybrid OpenFlow in a 10/40G ToR switch: http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html The example can be modified to target NTP mon_getlist requests and responses using the following sFlow-RT flow definition: {'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'} or to target DNS ANY requests: {keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'} The OpenFlow block control can be modified to selectively filter UDP traffic based on the identified UDP source port and destination IP address. Vendors are adding new SDN capabilities to their platforms (often as software upgraded), so it's worth taking a look and seeing what is possible. Peter On Sun, Feb 2, 2014 at 7:38 PM, Larry Sheldon wrote: > On 2/2/2014 9:17 PM, ryangard at gmail.com wrote: >> >> I'd hate to think that NetOps would be so heavy handed in blocking >> all of UDP, as this would essentially halt quite a bit of audio/video >> traffic. That being said, there's still quite the need for protocol >> improvement when making use of UDP, but blocking UDP as a whole is >> definitely not a resolution, and simply creating a wall that not only >> keeps the abusive traffic out, but keeps legitimate traffic from >> flowing freely as it should. > > > "We had to burn down the village to save it." > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From job.snijders at hibernianetworks.com Mon Feb 3 17:52:18 2014 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Mon, 3 Feb 2014 12:52:18 -0500 Subject: BGP peer traffic monitoring In-Reply-To: <50710E9A7E64454C974049FC998EB655018DE82C@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655018DE82C@03-exchange.lti.local> Message-ID: <20140203175218.GA81866@Eleanor.local> On Mon, Feb 03, 2014 at 11:48:04AM -0600, Dennis Burgess wrote: > I have a router with about 20 peers, most are all on a single port > (local exchange), how is everyone monitoring traffic to individual > peers? Use something like IPFIX, NetFlow, sFlow and take a look at these two tools: http://pmacct.net/ https://github.com/manuelkasper/AS-Stats -- Kind regards, Job -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From andre at operations.net Mon Feb 3 18:05:46 2014 From: andre at operations.net (Andre Gironda) Date: Mon, 3 Feb 2014 21:05:46 +0300 Subject: Do network diagnostic tools need upgrade? In-Reply-To: References: Message-ID: Oldies, but goodies: shaperprobe (1st), pchar (3rd), tcptrace.org, lft (4th), iftop, nsping (2nd), iperf, sjitter, pathneck (3rd) These are newer -- http://www.internet2.edu/products-services/performance-monitoring/performance-tools/ (OWAMP, 2nd) -- http://paris-traceroute.net (4th) -- http://packetdrill.googlecode.com dre On Mon, Feb 3, 2014 at 4:33 PM, Ammar Salih wrote: > Hello NANOG list members, > > I have a question for you, are you happy with the current network > diagnostic tools, like ping, trace route .. etc, don't you think it's time > to have an upgraded version of icmp protocol? from my side there is a lot > that I can NOT do with current tools and protocols, here are few scenarios, > and I would like to hear yours: > > > > First scenario: > > To be able to troubleshoot advanced networks with complex QoS and > policy-based routing configuration, where ping, traceroute and other > network diagnostic tools do not provide accurate readings, for example, you > are troubleshooting a web server with ping, and it looks functioning quite > well (packet loss and round trip time is all good), but web services are > still significantly slow, the fact is icmp and tcp:80 might have different > priorities and bandwidth limits on each router along the path between the > client and the server, in this case, network admins usually use telnet > applications like (Paping), well it may help if the forward and return path > of all packets are exactly the same. > > > > Second scenario: > > So another possible scenario is that you need to determine readings for > forward and return paths, TraceRoute for example gives you forward path > only using icmp. But what if you need to troubleshoot a VoIP server for > example, assuming that packets return path might not be the same as forward > path. > > > > Third scenario: > > One of the most common problems in networking, is that you don't have > access to all equipment between client and server, but you have to > troubleshoot the path between them and to understand where the problem > exactly is in order to contact the right person without having the > privilege to check the configuration on each router. > > > > Fourth scenario: > > Also, with trace route you can't determine the actual path, for example, > the router may direct http traffic to proxy server while leaving other > traffic going through a different hop. > From Valdis.Kletnieks at vt.edu Mon Feb 3 18:05:12 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Feb 2014 13:05:12 -0500 Subject: Do network diagnostic tools need upgrade? In-Reply-To: Your message of "Mon, 03 Feb 2014 16:33:34 +0300." References: Message-ID: <22407.1391450712@turing-police.cc.vt.edu> On Mon, 03 Feb 2014 16:33:34 +0300, Ammar Salih said: > I have a question for you, are you happy with the current network > diagnostic tools, like ping, trace route .. etc, don't you think it's time > to have an upgraded version of icmp protocol? from my side there is a lot > that I can NOT do with current tools and protocols, here are few scenarios, > and I would like to hear yours: Upgrading ICMP protocol is... challenging. I wouldn't even bother with trying to do anything with IPv4. Might be some options for IPv6, *IF* you can provide a *specific* proposal that looks worth the added code and router complexity.... Also, remember that most routers will do packet forwarding in hardware if they can just suck in bits on one interface and toss them out another - but if they have to do stuff like create and send an ICMP TTL Exceeded packet, you end up on the control plane and probably rate-limited. > applications like (Paping), well it may help if the forward and return path > of all packets are exactly the same. That's a routing problem, not an ICMP problem. As are the remainder of your examples. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Mon Feb 3 18:16:41 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Feb 2014 13:16:41 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal wrote: > Why burn the village when only one house is the problem? I thought > there might be some interest in hearing about work being done to use > SDN to automatically configure filtering in existing switches and > routers to mitigate flood attacks. > that's great... who's got sdn capable gear in deployments today? with code and OSS stuff to deal with random SDN pokery? and who has spare tcam/etc to deal with said pokery of 'block the attack-du-jour' ? There's certainly the case that you could drop acls/something on equipment to selectively block the traffic that matters... I suspect in some cases the choice was: "50% of the edge box customers on this location are a problem, block it across the board here instead of X00 times" (see concern about tcam/etc problems) > Real-time analytics based on measurements from switches/routers > (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid > OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the > switches/routers to selectively filter traffic based on UDP port and > IP source / destination. By deploying a DDoS mitigation SDN > application, providers can use their existing infrastructure to > protect their own and their customers networks from flood attacks, and > generate additional revenue by delivering flood protection as a value > added service. yup, that sounds wonderous... and I'm sure that in the future utopian world (like 7-10 years from now, based on age-out of gear and OSS IT change requirements) we'll see more of this. I don't think you'll see much (in terms of edge ports on the network today) of this happening 'right now' though. > https://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case/ > http://events.linuxfoundation.org/sites/events/files/slides/flow-aware-real-time-sdn-analytics-odl-summit-v2.pdf > > Specifically looking at sFlow, large flood attacks can be detected > within a second. The following article describes a simple example > using integrated hybrid OpenFlow in a 10/40G ToR switch: hopefully there's some clamp on how much change per device/port you plan too? :) I'd hate to see the RP/RE/etc get so busy programming tcam that bgp/isis/ospf/etc flaps :( > > http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html > > The example can be modified to target NTP mon_getlist requests and > responses using the following sFlow-RT flow definition: > > {'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'} > > or to target DNS ANY requests: > > {keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'} > this also assume almost 1:1 sampling... which might not be feasible either...otherwise you'll be seeing fairly lossy results, right? > The OpenFlow block control can be modified to selectively filter UDP > traffic based on the identified UDP source port and destination IP > address. > hopefully your OSS and netflow/sflow collection isn't also being used for traffic engineering/capacity planning purposes? else... you might get odd results from that infrastructure with such changes to the sflow/netflow sender platform. > Vendors are adding new SDN capabilities to their platforms (often as > software upgraded), so it's worth taking a look and seeing what is > possible. the device side is PROBABLY the simple side of the equation for most people... > > On Sun, Feb 2, 2014 at 7:38 PM, Larry Sheldon wrote: >> On 2/2/2014 9:17 PM, ryangard at gmail.com wrote: >>> >>> I'd hate to think that NetOps would be so heavy handed in blocking >>> all of UDP, as this would essentially halt quite a bit of audio/video >>> traffic. That being said, there's still quite the need for protocol >>> improvement when making use of UDP, but blocking UDP as a whole is >>> definitely not a resolution, and simply creating a wall that not only >>> keeps the abusive traffic out, but keeps legitimate traffic from >>> flowing freely as it should. >> >> >> "We had to burn down the village to save it." >> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >> > From fergdawgster at mykolab.com Mon Feb 3 18:23:03 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 03 Feb 2014 10:23:03 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: <52EFDE87.2050307@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/2/2014 2:17 PM, Cb B wrote: > And, i agree bcp38 would help but that was published 14 years ago. But what? Are you somehow implying that because BCP38 was "...published 14 years ago" (RFC2267 was initially published in 1998, and it was subsequently replaced by RFC2827)? I hope not, because BCP38 filtering would still help stop spoofed traffic now perpetuating these attacks, 14 years after BCP38 was published, because spoofing is at the root of this problem (reflection/amplification attacks). This horse is not dead, and still deserves a lot of kicking. $.02, - - ferg (co-author of BCP38) - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLv3ocACgkQKJasdVTchbLhowEAuO9DSQiRswVeqpHSccHo060h cqmIB8XlaNkzEPQw1w0A/0G6cjvtWBiJfwWbWoTY7X3RRMHeN36RkYR+2TonyNBi =W2wU -----END PGP SIGNATURE----- From johnl at iecc.com Mon Feb 3 18:23:31 2014 From: johnl at iecc.com (John Levine) Date: 3 Feb 2014 18:23:31 -0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Message-ID: <20140203182331.8608.qmail@joyce.lan> >In regards to anti-spoofing measures - I think there a couple of vectors about the latest NTP attack >where more rigorous client-side anti-spoofing could help but will not solve it overall. Most NTP servers only send legitimate traffic to a handful of masters, often in the ntp.org pool, and to peers and clients on their own network. I know that when I adjusted my NTP config to stop responding to traffic other than its ntp.org masters and the local LAN, the outbound DDoS traffic stopped. It took a while for the bad guys to notice, so I added some packet filters to limit the load on the NTP daemon. It seems thata hosts sending large amounts of NTP traffic over the public Internet can be safely filtered if you don't already know that it's one of the handful that's in the ntp.org pools or another well known NTP master. R's, John From Jack.Stonebraker at mygrande.com Mon Feb 3 18:37:19 2014 From: Jack.Stonebraker at mygrande.com (Jack Stonebraker) Date: Mon, 3 Feb 2014 18:37:19 +0000 Subject: BGP peer traffic monitoring In-Reply-To: <50710E9A7E64454C974049FC998EB655018DE82C@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655018DE82C@03-exchange.lti.local> Message-ID: <1C88157B8801CB448C108286C81ECB630B3A4F@SRV-SAM-MBOX02.lan.thrifty.net> We perform MAC Based accounting on our IX interface and that allows us to monitor / graph traffic based off MAC address instead of being limited to the aggregate data of a single interface. Here's the JUNOS way of doing it, I'm sure other vendors have their equivalent. http://www.juniper.net/techpubs/en_US/junos13.2/topics/usage-guidelines/interfaces-configuring-mac-address-accounting.html JJ Stonebraker IP Network Engineering Grande Communications 512.878.5627 -----Original Message----- From: Dennis Burgess [mailto:dmburgess at linktechs.net] Sent: Monday, February 03, 2014 11:48 AM To: NANOG list Subject: BGP peer traffic monitoring I have a router with about 20 peers, most are all on a single port (local exchange), how is everyone monitoring traffic to individual peers? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From Valdis.Kletnieks at vt.edu Mon Feb 3 18:38:58 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Feb 2014 13:38:58 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "03 Feb 2014 18:23:31 +0000." <20140203182331.8608.qmail@joyce.lan> References: <20140203182331.8608.qmail@joyce.lan> Message-ID: <26846.1391452738@turing-police.cc.vt.edu> On 03 Feb 2014 18:23:31 +0000, "John Levine" said: > It seems thata hosts sending large amounts of NTP traffic over the > public Internet can be safely filtered if you don't already know that > it's one of the handful that's in the ntp.org pools or another well > known NTP master. You have that backwards - you can (possibly) safely filter it if you can establish *for certain* that it *isn't* in the ntp.org pools. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jared at puck.nether.net Mon Feb 3 18:39:10 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 3 Feb 2014 13:39:10 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202204446.50900.qmail@joyce.lan> Message-ID: <13C99B62-0948-4DB1-9C12-4AA027EE2AFC@puck.nether.net> On Feb 3, 2014, at 12:45 AM, Michael DeMan wrote: > The recently publicized mechanism to leverage NTP servers for amplified DoS attacks is seriously effective. > I had a friend who had a local ISP affected by this Thursday and also another case where just two asterisk servers saturated a 100mbps link to the point of unusability. > Once more - this exploit is seriously effective at using bandwidth by reflection. The challenge I see is there's some hosts like this one: [jared at nowherelikehome ]$ ntpq -c rv 111.107.252.142 associd=0 status=06f4 leap_none, sync_ntp, 15 events, freq_mode, version="ntpd 4.2.0-r Fri Jul 22 09:50:16 JST 2011 (1)", processor="seil5", system="NetBSD/3.1_STABLE", leap=00, stratum=5, precision=-18, rootdelay=9.138, rootdispersion=132.247, peer=58012, refid=172.22.203.213, reftime=d685a094.9c806290 Sun, Jan 19 2014 0:53:40.611, poll=10, clock=d69a5d3c.c6b1a2a4 Mon, Feb 3 2014 18:23:56.776, state=4, offset=-0.598, frequency=-1.463, jitter=0.229, stability=0.042 This host will happily generate 100GB response to a single packet. They even have advisories posted: http://www.seil.jp/support/security/a01411.html Getting the information into the admin is hard. Time zones, language barriers, folks understanding why having unmaintained NTP hosts out there can be a significant issue. We found many ILO/IPMI interfaces that have NTP you can't do anything about (no filters, etc) - let alone patch .. Through ACL (hopefully not) or folks fixing hosts the following trend is observable in # of unique hosts that respond to NTP packets: 1529866 2014-01-10 1402569 2014-01-17 803156 2014-01-24 564027 2014-01-31 I will say that an awful lot of "firewall" operators out there seem to now be saying "NTP BAD" and generating panic'ed emails about NTP traffic. - Jared From dougb at dougbarton.us Mon Feb 3 18:51:37 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 03 Feb 2014 10:51:37 -0800 Subject: [NANOG-announce] NANOG On The Road - San Diego In-Reply-To: References: Message-ID: <52EFE539.1000203@dougbarton.us> This event sounds like a lot of fun, and I look forward to attending. :) Just curious if anyone wants to participate in an informal PGP key signing activity while we're there? I'm thinking an old fashioned "everyone brings their own slips of paper" type thing, but if there is sufficient interest I wouldn't mind helping to coordinate a key ring and printed sheets ... Doug On 01/29/2014 07:17 PM, Betty Burke wrote: > Colleagues: > > In partnership, the American Registry for Internet Numbers (ARIN) and the > North American Network Operators Group (NANOG) will bring ARIN+NANOG on the > Road to San Diego, CA on Tuesday, February 25, 2014. The one day event > will be held at the Handerly Hotel & Resort. > > Please pass along this information to those who would benefit from > attending a free event featuring educational sessions, great discussions, > and networking opportunities! > > Morning sessions will get attendees up to speed on Internet number resource > management, ARIN technical services, current policy discussions and more. > Afternoon sessions will feature NANOG Tutorials on Network Security, IPv6, > Traceroutes, BGB, including an update on the NANOG Best Current Operational > Practice (BCOP) project. > > Complete information and meeting links are available on the NANOG > website > . > > Should you have any questions, please feel free to send them to > nanog-support at nanog.org. > > Sincerely, > Betty From alvarezp at alvarezp.ods.org Mon Feb 3 18:59:14 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 03 Feb 2014 10:59:14 -0800 Subject: Do network diagnostic tools need upgrade? In-Reply-To: References: Message-ID: <52EFE702.2030103@alvarezp.ods.org> On 02/03/2014 05:33 AM, Ammar Salih wrote: > Hello NANOG list members, > > I have a question for you, are you happy with the current network > diagnostic tools, like ping, trace route .. etc, What tools are you referring to by "..."? There are many others. I like tcptraceroute (there are two variants of it) and mtr. > don't you think it's time > to have an upgraded version of icmp protocol? What is it that you are thinking? ICMP is for signaling between machines. Increasing signaling for human diagnostics can lead to reconnaissance attacks. We don't want yet another option for some to incorrectly block ICMP [1], which in turn leads to other problems. [1] ... when they want to just block ICMP echo and reply, which is also bad enough and must be done really selectively. > First scenario: > > To be able to troubleshoot advanced networks with complex QoS and > policy-based routing configuration, where ping, traceroute and other > network diagnostic tools do not provide accurate readings, for example, you > are troubleshooting a web server with ping, and it looks functioning quite > well (packet loss and round trip time is all good), but web services are > still significantly slow, the fact is icmp and tcp:80 might have different > priorities and bandwidth limits on each router along the path between the > client and the server, in this case, network admins usually use telnet > applications like (Paping), well it may help if the forward and return path > of all packets are exactly the same. tcptraceroute. > Second scenario: > > So another possible scenario is that you need to determine readings for > forward and return paths, TraceRoute for example gives you forward path > only using icmp. But what if you need to troubleshoot a VoIP server for > example, assuming that packets return path might not be the same as forward > path. It depends. Asymmetric routing is not necessarily bad unless it causes a problem like packet loss, high latency, etc. For example, if the return path has packet loss but you should 'hopefully' (yeah I know...) notice it in the traceroute if you increment the probe count or run it twice. Or try mtr, a periodic traceroute with different statistics presentation that significantly reduces the 'hopefully' problem. > Third scenario: > > One of the most common problems in networking, is that you don't have > access to all equipment between client and server, but you have to > troubleshoot the path between them and to understand where the problem > exactly is in order to contact the right person without having the > privilege to check the configuration on each router. This one's more difficult but also "it depends". State a specific problem case. > Fourth scenario: > > Also, with trace route you can't determine the actual path, for example, > the router may direct http traffic to proxy server while leaving other > traffic going through a different hop. tcptraceroute. From brak at gameservers.com Mon Feb 3 17:11:47 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 03 Feb 2014 12:11:47 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52EFA446.303@earthlink.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> Message-ID: <52EFCDD3.6050601@gameservers.com> Huh? The issue with NTP relates to the monlist command (and a few others). These are management queries, and are not critical to the operation of a NTP server. You can disable these quite easily, and still run a NTP server that provides accurate time services. On 2/3/2014 9:14 AM, TGLASSEY wrote: > How about this - I have proposed to NIST we start filtering - realize > that the NIST ITS program itself was setup to run NTP in an open > access mode - we host a dozen or so of those systems and so we get hit > all the time. > > The solution is actually not running timing services across UDP > because of the hand shaking over the open Internet - and that > obviously isnt going to happen. > > My suggestion is that for those that need access we set up VLAN > trunked private networking models to your ISP MPOE as it were in a > digital context. > > If this interests you contact me off list. > > Todd Glassey - USTiming.ORG > > On 2/2/2014 7:17 PM, ryangard at gmail.com wrote: >> I'd hate to think that NetOps would be so heavy handed in blocking >> all of UDP, as this would essentially halt quite a bit of audio/video >> traffic. That being said, there's still quite the need for protocol >> improvement when making use of UDP, but blocking UDP as a whole is >> definitely not a resolution, and simply creating a wall that not only >> keeps the abusive traffic out, but keeps legitimate traffic from >> flowing freely as it should. >> Sent on the TELUS Mobility network with BlackBerry >> >> -----Original Message----- >> From: Cb B >> Date: Sun, 2 Feb 2014 15:09:55 >> To: Matthew Petach >> Cc: >> Subject: Re: TWC (AS11351) blocking all NTP? >> >> On Feb 2, 2014 2:54 PM, "Matthew Petach" wrote: >>> On Sun, Feb 2, 2014 at 2:17 PM, Cb B wrote: >>> >>>> On Feb 2, 2014 8:35 AM, "Jonathan Towne" wrote: >>>>> The provider has kindly acknowledged that there is an issue, and are >>>>> working on a resolution. Heads up, it may be more than just my >> region. >>>> And not just your provider, everyone is dealing with UDP amp attacks. >>>> >>>> These UDP based amp attacks are off the charts. Wholesale blocking of >>>> traffic at the protocol level to mitigate 10s to 100s of gigs of ddos >>>> traffic is not "knee jerk", it is the right thing to do in a world >>>> where >>>> bcp 38 is far from universal and open dns servers, ntp, chargen, and >>>> whatever udp 172 is run wild. >>>> >>>> People who run networks know what it takes to restore service. And >>>> increasingly, that will be clamping ipv4 UDP in the plumbing, both >>>> reactively and proactively. >>>> >>> >>> Please note that it's not that UDP is at fault here; it's >>> applications that are structured to respond to small >>> input packets with large responses. >>> >> I dont want to go into fault, there is plenty of that to go around. >> >>> If NTP responded to a single query with a single >>> equivalently sized response, its effectiveness as >>> a DDoS attack would be zero; with zero amplification, >>> the volume of attack traffic would be exactly equivalent >>> to the volume of spoofed traffic the originator could >>> send out in the first place. >>> >>> I agree the source obfuscation aspect of UDP can be >>> annoying, from the spoofing perspective, but that >>> really needs to be recognized to be separate from >>> the volume amplification aspect, which is an application >>> level issue, not a protocol level issue. >>> >> Source obfuscation is not annoying. Combined with amplification, it >> is the >> perfect storm for shutting down networks... whereby the only solution >> is to >> shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, >> patches boxes, and so on. >> >> My point is: dont expect these abbused services on UDP to last. We have >> experience in access networks on how to deal with abused protocols. >> Here is >> one reference >> >> http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ >> >> >> My crystal ball says all of UDP will show up soon. >> >> CB >> >>> Thanks! >>> >>> Matt >>> PS--yes, I know it would completely change the >>> dynamics of the internet as we know it today to >>> shift to a 1:1 correspondence between input >>> requests and output replies...but it *would* >>> have a nice side effect of balancing out traffic >>> ratios in many places, altering the settlement >>> landscape in the process. ;) > From jared at puck.nether.net Mon Feb 3 19:15:02 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 3 Feb 2014 14:15:02 -0500 Subject: Do network diagnostic tools need upgrade? In-Reply-To: <52EFE702.2030103@alvarezp.ods.org> References: <52EFE702.2030103@alvarezp.ods.org> Message-ID: On Feb 3, 2014, at 1:59 PM, Octavio Alvarez wrote: > On 02/03/2014 05:33 AM, Ammar Salih wrote: >> Hello NANOG list members, >> >> I have a question for you, are you happy with the current network >> diagnostic tools, like ping, trace route .. etc, > > What tools are you referring to by "..."? There are many others. I like > tcptraceroute (there are two variants of it) and mtr. There are lesser known options that are used by folks, eg: ping record-route. One could certainly use those available tools, but most folks have a hard enough time interpreting traceroute output. I've seen customers complain about performance to have us show them it's on their network, or their firewall modules, etc.. Having statistics on network usage/errors/drops is incredible useful in isolating the performance limitations. Knowing that a firewall maxes at 350Mb/s is as equally useful as having protocol extensions to collect the data. One of my early experiences with a sysadmin who only cared about the application/OS was "the router is a black box that gets my packets there". Knowing the behavior beyond there is also important (how latency/loss impacts tcp/udp/application performance for example). Most importantly, keeping an open mind when troubleshooting is helpful. Sometimes you find something unexpected. (eg: uRPF drops when responding IP is mapped-v4-in-v6 from within 6PE network). - Jared From rdobbins at arbor.net Mon Feb 3 19:19:55 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 19:19:55 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: <3C431BEB-D39E-47C7-9358-CB958825F885@arbor.net> On Feb 4, 2014, at 12:42 AM, Peter Phaal wrote: > Real-time analytics based on measurements from switches/routers (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid > OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the switches/routers to selectively filter traffic based on UDP port and > IP source / destination. By deploying a DDoS mitigation SDN application, providers can use their existing infrastructure to > protect their own and their customers networks from flood attacks, and generate additional revenue by delivering flood protection as a value > added service. This is certainly a general capability set towards which many operators are evolving (and it's always amusing how you leave out NetFlow, which many operators use, but include sFlow, which very few operators use, heh), but it's going to be quite some time before this sort of thing is practical and widely-deployale. Believe me, I've been working towards this vision for many years. It isn't going to happen overnight. > Specifically looking at sFlow, large flood attacks can be detected within a second. And with NetFlow, and with IPFIX - the first of which is widely deployed today, and the second of which will be widely deployed in future. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From Joel.Snyder at Opus1.COM Mon Feb 3 19:21:56 2014 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 03 Feb 2014 20:21:56 +0100 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: Message-ID: <52EFEC54.2060905@Opus1.COM> > It seems thata hosts sending large amounts of NTP traffic over the > public Internet can be safely filtered if you don't already know that > it's one of the handful that's in the ntp.org pools or another well > known NTP master. Speaking as one of the 3841 servers in the pool.ntp.org pool, I'm happy to be described as a "handful," something my mother used to say, but I do feel obligated to point out that it's a pretty big handful especially if you want to be fiddling ACLs on an hourly basis which is pretty much what it takes. And, of course, if you're one of that handful, then you've pretty much got to allow that NTP traffic in, although you're also probably, hopefully, clue-full enough not to let random hosts make you a DDoS accelerator. (the other) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From peter.phaal at gmail.com Mon Feb 3 19:42:17 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 3 Feb 2014 11:42:17 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow wrote: > On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal wrote: >> Why burn the village when only one house is the problem? I thought >> there might be some interest in hearing about work being done to use >> SDN to automatically configure filtering in existing switches and >> routers to mitigate flood attacks. >> > > that's great... who's got sdn capable gear in deployments today? with > code and OSS stuff to deal with random SDN pokery? and who has spare > tcam/etc to deal with said pokery of 'block the attack-du-jour' ? > > There's certainly the case that you could drop acls/something on > equipment to selectively block the traffic that matters... I suspect > in some cases the choice was: "50% of the edge box customers on this > location are a problem, block it across the board here instead of X00 > times" (see concern about tcam/etc problems) I agree that managing limited TCAM space is critical to the scaleability of any mitigation solution. However, tying up TCAM space on every edge device with filters to prevent each new threat is likely to be less scaleable than a measurement driven control that only takes a TCAM slot on a device when an active attack is detected transiting that device. >> Real-time analytics based on measurements from switches/routers >> (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid >> OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the >> switches/routers to selectively filter traffic based on UDP port and >> IP source / destination. By deploying a DDoS mitigation SDN >> application, providers can use their existing infrastructure to >> protect their own and their customers networks from flood attacks, and >> generate additional revenue by delivering flood protection as a value >> added service. > > yup, that sounds wonderous... and I'm sure that in the future utopian > world (like 7-10 years from now, based on age-out of gear and OSS IT > change requirements) we'll see more of this. I don't think you'll see > much (in terms of edge ports on the network today) of this happening > 'right now' though. The current 10G upgrade cycle provides an opportunity to deploy equipment that is SDN capable. The functionality required for this use case is supported by current generation merchant silicon and is widely available right now in inexpensive switches. >> Specifically looking at sFlow, large flood attacks can be detected >> within a second. The following article describes a simple example >> using integrated hybrid OpenFlow in a 10/40G ToR switch: > > hopefully there's some clamp on how much change per device/port you > plan too? :) I'd hate to see the RP/RE/etc get so busy programming > tcam that bgp/isis/ospf/etc flaps :( With integrated hybrid OpenFlow, there is very little activity on the OpenFlow control plane. The normal BGP, ECMP, LAG, etc. control planes handles forwarding of packets. OpenFlow is only used to selectively override specific FIB entries. I2RS provides a similar capability to selectively override RIB entries and implement controls. However, I don't know if any vendors are shipping I2RS capable routers today. Typical networks probably only see a few DDoS attacks an hour at the most, so pushing a few rules an hour to mitigate them should have little impact on the switch control plane. A good working definition of a large flow is 10% of a link's bandwidth. If you only trigger actions for large flows then in the worst case you would only require 10 rules per port to change how these flows are treated. > >> >> http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html >> >> The example can be modified to target NTP mon_getlist requests and >> responses using the following sFlow-RT flow definition: >> >> {'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'} >> >> or to target DNS ANY requests: >> >> {keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'} >> > > this also assume almost 1:1 sampling... which might not be feasible > either...otherwise you'll be seeing fairly lossy results, right? Actually, to detect large flows (defined as 10% of link bandwidth) within a second, you would only require the following sampling rates: 1G link, sampling rate = 1-in-1,000 (large flow >= 100M bit/s) 10G link, sampling rate = 1-in-10,000 (large flow >= 1G bit/s) 40G link, sampling rate = 1-in-40,000 (large flow >= 4G bit/s 100G link, sampling rate = 1-in-100,000 (large flow >= 10G bit/s) These sampling rates are realistically achievable in production networks (enabling monitoring on all ports) and would allow you to detect the specific IP destination and UDP source port associated with a flood attack, and the switches in the attack path, within a second. > >> The OpenFlow block control can be modified to selectively filter UDP >> traffic based on the identified UDP source port and destination IP >> address. >> > > hopefully your OSS and netflow/sflow collection isn't also being used > for traffic engineering/capacity planning purposes? else... you might > get odd results from that infrastructure with such changes to the > sflow/netflow sender platform. This use case might be more problematic for NetFlow since obtaining the measurements may affect the router configuration (flow cache definitions) and other applications that depend on them (like capacity planning). In the case of sFlow monitoring, the flow cache is built externally and you can feed the sFlow to multiple independent analysis tools without risk of interference. http://blog.sflow.com/2013/05/software-defined-analytics.html From rdobbins at arbor.net Mon Feb 3 19:46:14 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 19:46:14 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52EFCDD3.6050601@gameservers.com> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> <52EFCDD3.6050601@gameservers.com> Message-ID: <908518FF-C5FD-490D-9263-E5D62EE6C902@arbor.net> On Feb 4, 2014, at 12:11 AM, Brian Rak wrote: > You can disable these quite easily, and still run a NTP server that provides accurate time services. Concur 100% - although it should be noted that 1:1 reflection without any amplification is also quite useful to attackers. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From brak at gameservers.com Mon Feb 3 20:09:08 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 03 Feb 2014 15:09:08 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <908518FF-C5FD-490D-9263-E5D62EE6C902@arbor.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> <52EFCDD3.6050601@gameservers.com> <908518FF-C5FD-490D-9263-E5D62EE6C902@arbor.net> Message-ID: <52EFF764.6080301@gameservers.com> On 2/3/2014 2:46 PM, Dobbins, Roland wrote: > On Feb 4, 2014, at 12:11 AM, Brian Rak wrote: > >> You can disable these quite easily, and still run a NTP server that provides accurate time services. > Concur 100% - although it should be noted that 1:1 reflection without any amplification is also quite useful to attackers. > That's true, but there are countless services out there that could be abused in such a way. It's pretty much the same issue with DNS, even authoritative-only servers can be abused for reflection. Securing everything that could possibly be used for reflection is going to be a long and painful process, preventing this specific amplification attack is pretty easy. NTP clients have a long history of poor implementations, so the server already has rate limiting built in. While rate limiting outgoing replies isn't a perfect solution, it's significantly better then no rate limiting (for the curious, add 'limited' to your 'restrict default' lines to enable rate limiting. This doesn't help with the current amplification issues, but will help should someone just be abusing NTP servers for reflection). From rdobbins at arbor.net Mon Feb 3 20:21:06 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 20:21:06 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52EFF764.6080301@gameservers.com> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <519287566-1391397452-cardhu_decombobulator_blackberry.rim.net-2100547830-@b3.c8.bise6.blackberry> <52EFA446.303@earthlink.net> <52EFCDD3.6050601@gameservers.com> <908518FF-C5FD-490D-9263-E5D62EE6C902@arbor.net> <52EFF764.6080301@gameservers.com> Message-ID: <8A281E7F-F9B4-4E6F-B97F-37DDFFF0D568@arbor.net> On Feb 4, 2014, at 3:09 AM, Brian Rak wrote: > It's pretty much the same issue with DNS, even authoritative-only servers can be abused for reflection. They are, every minute of every day - and they provide amplification, too. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bryan at digitalocean.com Mon Feb 3 19:44:33 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Mon, 3 Feb 2014 14:44:33 -0500 Subject: Do network diagnostic tools need upgrade? In-Reply-To: References: <52EFE702.2030103@alvarezp.ods.org> Message-ID: I like observium for monitoring gear, tons of information, great way to find erroring fiber over thousands of devices and caught some memory leaks prior to impacting things. This is in addition to flow data of course. Bryan DigitalOcean We're Hiring From johnl at iecc.com Mon Feb 3 20:29:21 2014 From: johnl at iecc.com (John R. Levine) Date: 3 Feb 2014 15:29:21 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52EFEC54.2060905@Opus1.COM> References: <52EFEC54.2060905@Opus1.COM> Message-ID: >> It seems thata hosts sending large amounts of NTP traffic over the >> public Internet can be safely filtered if you don't already know that >> it's one of the handful that's in the ntp.org pools or another well >> known NTP master. > > Speaking as one of the 3841 servers in the pool.ntp.org pool, I'm happy to be > described as a "handful," something my mother used to say, but I do feel > obligated to point out that it's a pretty big handful especially if you want > to be fiddling ACLs on an hourly basis which is pretty much what it takes. I was thinking that the ntp.org servers on any particular network are a small set of exceptions to a general rule to rate limit outgoing NTP traffic. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From morrowc.lists at gmail.com Mon Feb 3 20:38:49 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Feb 2014 15:38:49 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: On Mon, Feb 3, 2014 at 2:42 PM, Peter Phaal wrote: > On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow > wrote: >> On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal wrote: >> There's certainly the case that you could drop acls/something on >> equipment to selectively block the traffic that matters... I suspect >> in some cases the choice was: "50% of the edge box customers on this >> location are a problem, block it across the board here instead of X00 >> times" (see concern about tcam/etc problems) > > I agree that managing limited TCAM space is critical to the > scaleability of any mitigation solution. However, tying up TCAM space > on every edge device with filters to prevent each new threat is likely yup, there's a tradeoff, today it's being made one way, tomorrow perhaps a different way. My point was that today the percentage of sdn capable devices is small enough that you still need a decimal point to measure it. (I bet, based on total devices deployed) The percentage of oss backend work done to do what you want is likely smaller... the folk in NZ-land (Citylink, reannz ... others - find josh baily / cardigan) are making some strides, but only in the exchange areas so far. fun stuff... but not the deployed gear as an L2/L3 device in TWC/Comcast/Verizon. >>> Real-time analytics based on measurements from switches/routers >>> (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid >>> OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the >>> switches/routers to selectively filter traffic based on UDP port and >>> IP source / destination. By deploying a DDoS mitigation SDN >>> application, providers can use their existing infrastructure to >>> protect their own and their customers networks from flood attacks, and >>> generate additional revenue by delivering flood protection as a value >>> added service. >> >> yup, that sounds wonderous... and I'm sure that in the future utopian >> world (like 7-10 years from now, based on age-out of gear and OSS IT >> change requirements) we'll see more of this. I don't think you'll see >> much (in terms of edge ports on the network today) of this happening >> 'right now' though. > > The current 10G upgrade cycle provides an opportunity to deploy by 'current 10g upgrade cycle' you mean the one that happened 2-5 yrs ago? or somethign newer? did you mean 100G? > equipment that is SDN capable. The functionality required for this use > case is supported by current generation merchant silicon and is widely > available right now in inexpensive switches. > right... and everyone is removing their vendor supported gear and replacing it with pica8 boxes? The reality is that as speeds/feeds have increased over the last while basic operations techiques really haven't. Should they? maybe? will they? probably? is that going to happen on a dime? nope. Again, I suspect you'll see smaller deployments of sdn-like stuff 'soon' and larger deployments when people are more comfortable with the operations/failure modes that change. >>> Specifically looking at sFlow, large flood attacks can be detected >>> within a second. The following article describes a simple example >>> using integrated hybrid OpenFlow in a 10/40G ToR switch: >> >> hopefully there's some clamp on how much change per device/port you >> plan too? :) I'd hate to see the RP/RE/etc get so busy programming >> tcam that bgp/isis/ospf/etc flaps :( > > With integrated hybrid OpenFlow, there is very little activity on the > OpenFlow control plane. The normal BGP, ECMP, LAG, etc. control planes > handles forwarding of packets. OpenFlow is only used to selectively > override specific FIB entries. that didn't really answer the question :) if I have 10k customers behind the edge box and some of them NOW start being abused, then more later and that mix changes... if it changes a bunch because the attacker is really attackers. how fast do I change before I can't do normal ops anymore? > Typical networks probably only see a few DDoS attacks an hour at the > most, so pushing a few rules an hour to mitigate them should have > little impact on the switch control plane. based on what math did you get 'few per hour?' As an endpoint (focal point) or as a contributor? The problem that started this discussion was being a contributor...which I bet happens a lot more often than /few an hour/. > A good working definition of a large flow is 10% of a link's > bandwidth. If you only trigger actions for large flows then in the > worst case you would only require 10 rules per port to change how > these flows are treated. 10% of a 1g link is 100mbps, For contributors to ntp attacks, many of the contributors are sending ONLY 300x the input, so less than 100mbps. On a 10g link it's 1G... even more hidden. This math and detection aren't HARD, but tuning it can be a bit challenging. >>> http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html >>> >>> The example can be modified to target NTP mon_getlist requests and >>> responses using the following sFlow-RT flow definition: >>> >>> {'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'} >>> >>> or to target DNS ANY requests: >>> >>> {keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'} >>> >> >> this also assume almost 1:1 sampling... which might not be feasible >> either...otherwise you'll be seeing fairly lossy results, right? > > Actually, to detect large flows (defined as 10% of link bandwidth) > within a second, you would only require the following sampling rates: your example requires seeing the 1st packet in a cycle, and seeing into the first packet. that's going to required either acceptance of loss (and gathering the loss in another rule/fashion) or 1:1 sampling to be assured of getting ALL of the DNS packets and seeing what was queried. I wonder also about privacy concerns with this. >> >>> The OpenFlow block control can be modified to selectively filter UDP >>> traffic based on the identified UDP source port and destination IP >>> address. >>> >> >> hopefully your OSS and netflow/sflow collection isn't also being used >> for traffic engineering/capacity planning purposes? else... you might >> get odd results from that infrastructure with such changes to the >> sflow/netflow sender platform. > > This use case might be more problematic for NetFlow since obtaining > the measurements may affect the router configuration (flow cache > definitions) and other applications that depend on them (like capacity > planning). In the case of sFlow monitoring, the flow cache is built > externally and you can feed the sFlow to multiple independent analysis > tools without risk of interference. > > http://blog.sflow.com/2013/05/software-defined-analytics.html provided your device does sflow and can export to more than one destination, sure. From jared at puck.nether.net Mon Feb 3 20:46:50 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 3 Feb 2014 15:46:50 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <52EFEC54.2060905@Opus1.COM> Message-ID: On Feb 3, 2014, at 3:29 PM, John R. Levine wrote: >>> It seems thata hosts sending large amounts of NTP traffic over the >>> public Internet can be safely filtered if you don't already know that >>> it's one of the handful that's in the ntp.org pools or another well >>> known NTP master. >> >> Speaking as one of the 3841 servers in the pool.ntp.org pool, I'm happy to be described as a "handful," something my mother used to say, but I do feel obligated to point out that it's a pretty big handful especially if you want to be fiddling ACLs on an hourly basis which is pretty much what it takes. > > I was thinking that the ntp.org servers on any particular network are a small set of exceptions to a general rule to rate limit outgoing NTP traffic. www.pool.ntp.org allows any NTP operator to opt-in to receive NTP traffic should their clock be available and accurate. - Jared From johnl at iecc.com Mon Feb 3 20:50:03 2014 From: johnl at iecc.com (John R. Levine) Date: 3 Feb 2014 15:50:03 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <52EFEC54.2060905@Opus1.COM> Message-ID: >> I was thinking that the ntp.org servers on any particular network are a small set of exceptions to a general rule to rate limit outgoing NTP traffic. > > www.pool.ntp.org allows any NTP operator to opt-in to receive NTP traffic should their clock be available and accurate. I believe you, but I don't believe that the set of ntp.org servers changes so rapidly that it is beyond the ability of network operators to handle the ones on their own networks as a special case. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From jgreco at ns.sol.net Mon Feb 3 17:29:21 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 3 Feb 2014 11:29:21 -0600 (CST) Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Message-ID: <201402031729.s13HTLRO033987@aurora.sol.net> > >> I was thinking that the ntp.org servers on any particular network are a small set of exceptions to a general rule to rate limit outgoing NTP traffic. > > > > www.pool.ntp.org allows any NTP operator to opt-in to receive NTP traffic should their clock be available and accurate. > > I believe you, but I don't believe that the set of ntp.org servers changes > so rapidly that it is beyond the ability of network operators to handle > the ones on their own networks as a special case. There's a bootstrap issue here. I'm guessing that you may be picturing a scenario where a network operator simply queries to obtain the list of ntp.org servers and special-cases their own. However, I believe that the system won't add NTP servers that appear to be nonresponsive to the list (bootstrap paradox), and in any case the list of returned servers is quite large and a response basically picks a few random servers, so it is quite difficult to know what servers are on your network in an automated fashion. ... 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. From mark at bernoullinetworks.com Mon Feb 3 21:02:11 2014 From: mark at bernoullinetworks.com (Mark Leonard) Date: Mon, 3 Feb 2014 14:02:11 -0700 Subject: -48VDC supply for home lab? Message-ID: Greetings NANOG'ers! I have a small home lab which I mostly use for learning and testing. I'm likely to receive some gear that needs negative 48VDC (ie: positive ground). Mains is a typical 120VAC, 60Hz. Can anyone recommend a power supply, reasonably priced, to go from 120VAC down to -48VDC at 10Amps? Something that fits in a two post rack would be preferred, but not required. Thanks, Mark From robertg at garlic.com Mon Feb 3 21:08:28 2014 From: robertg at garlic.com (Robert Glover) Date: Mon, 03 Feb 2014 13:08:28 -0800 Subject: -48VDC supply for home lab? In-Reply-To: References: Message-ID: <52F0054C.8030000@garlic.com> On 2/3/2014 1:02 PM, Mark Leonard wrote: > Greetings NANOG'ers! > > I have a small home lab which I mostly use for learning and testing. I'm > likely to receive some gear that needs negative 48VDC (ie: positive > ground). Mains is a typical 120VAC, 60Hz. > > Can anyone recommend a power supply, reasonably priced, to go from 120VAC > down to -48VDC at 10Amps? Something that fits in a two post rack would be > preferred, but not required. > > Thanks, > Mark > Mark, I'd recommend a Kepco PRR 48-22M. We have one in-office, used it for some -48VDC equipment (Adtran Total Access gear) that we tested in-office. Worked great, and can be found on eBay for under $400 -Bobby From Valdis.Kletnieks at vt.edu Mon Feb 3 21:07:52 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Feb 2014 16:07:52 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "Mon, 03 Feb 2014 11:29:21 -0600." <201402031729.s13HTLRO033987@aurora.sol.net> References: <201402031729.s13HTLRO033987@aurora.sol.net> Message-ID: <43561.1391461672@turing-police.cc.vt.edu> On Mon, 03 Feb 2014 11:29:21 -0600, Joe Greco said: > There's a bootstrap issue here. I'm guessing that you may be picturing > a scenario where a network operator simply queries to obtain the list of > ntp.org servers and special-cases their own. However, I believe that > the system won't add NTP servers that appear to be nonresponsive to the > list (bootstrap paradox), and in any case the list of returned servers > is quite large and a response basically picks a few random servers, so > it is quite difficult to know what servers are on your network in an > automated fashion. And even harder to identify stuff that's downstream at one of your customer's sites. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dougb at dougbarton.us Mon Feb 3 21:15:46 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 03 Feb 2014 13:15:46 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <52EFEC54.2060905@Opus1.COM> Message-ID: <52F00702.8030406@dougbarton.us> On 02/03/2014 12:50 PM, John R. Levine wrote: >>> I was thinking that the ntp.org servers on any particular network are >>> a small set of exceptions to a general rule to rate limit outgoing >>> NTP traffic. >> >> www.pool.ntp.org allows any NTP operator to opt-in to receive NTP >> traffic should their clock be available and accurate. > > I believe you, but I don't believe that the set of ntp.org servers > changes so rapidly that it is beyond the ability of network operators to > handle the ones on their own networks as a special case. The list is large enough, and changes often enough, that filtering on it isn't likely to be successful. Also, the list of what are "your" servers can change without warning. Doug From peter.phaal at gmail.com Mon Feb 3 22:16:36 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 3 Feb 2014 14:16:36 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: On Mon, Feb 3, 2014 at 12:38 PM, Christopher Morrow wrote: > On Mon, Feb 3, 2014 at 2:42 PM, Peter Phaal wrote: >> On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow >> wrote: >>> On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal wrote: > >>> There's certainly the case that you could drop acls/something on >>> equipment to selectively block the traffic that matters... I suspect >>> in some cases the choice was: "50% of the edge box customers on this >>> location are a problem, block it across the board here instead of X00 >>> times" (see concern about tcam/etc problems) >> >> I agree that managing limited TCAM space is critical to the >> scaleability of any mitigation solution. However, tying up TCAM space >> on every edge device with filters to prevent each new threat is likely > > yup, there's a tradeoff, today it's being made one way, tomorrow > perhaps a different way. My point was that today the percentage of sdn > capable devices is small enough that you still need a decimal point to > measure it. (I bet, based on total devices deployed) The percentage of > oss backend work done to do what you want is likely smaller... > > the folk in NZ-land (Citylink, reannz ... others - find josh baily / > cardigan) are making some strides, but only in the exchange areas so > far. fun stuff... but not the deployed gear as an L2/L3 device in > TWC/Comcast/Verizon. I agree that today most networks aren't SDN ready, but there are inexpensive switches on the market that can perform these functions and for providers that have them in their network, this is an option today. In some environments, it could also make sense to drop in a layer switches to monitor and control traffic entering / exiting the network. >> The current 10G upgrade cycle provides an opportunity to deploy > > by 'current 10g upgrade cycle' you mean the one that happened 2-5 yrs > ago? or somethign newer? did you mean 100G? I was referring to the current upgrade cycle in data centers, with servers connected with 10G rather than 1G adapters. The high volumes are driving down the cost of 10/40/100G switches. > >> equipment that is SDN capable. The functionality required for this use >> case is supported by current generation merchant silicon and is widely >> available right now in inexpensive switches. >> > > right... and everyone is removing their vendor supported gear and > replacing it with pica8 boxes? The reality is that as speeds/feeds > have increased over the last while basic operations techiques really > haven't. Should they? maybe? will they? probably? is that going to > happen on a dime? nope. Again, I suspect you'll see smaller > deployments of sdn-like stuff 'soon' and larger deployments when > people are more comfortable with the operations/failure modes that > change. Not just Pica8, most vendors (branded or white box) are using the same Broadcom merchant silicon, including Cisco, Juniper, Arista, Dell/Force10, Extreme etc.: http://blog.sflow.com/2014/01/drivers-for-growth.html > >>>> Specifically looking at sFlow, large flood attacks can be detected >>>> within a second. The following article describes a simple example >>>> using integrated hybrid OpenFlow in a 10/40G ToR switch: >>> >>> hopefully there's some clamp on how much change per device/port you >>> plan too? :) I'd hate to see the RP/RE/etc get so busy programming >>> tcam that bgp/isis/ospf/etc flaps :( >> >> With integrated hybrid OpenFlow, there is very little activity on the >> OpenFlow control plane. The normal BGP, ECMP, LAG, etc. control planes >> handles forwarding of packets. OpenFlow is only used to selectively >> override specific FIB entries. > > that didn't really answer the question :) if I have 10k customers > behind the edge box and some of them NOW start being abused, then more > later and that mix changes... if it changes a bunch because the > attacker is really attackers. how fast do I change before I can't do > normal ops anymore? Good point - the proposed solution is most effective for protecting customers that are targeted by DDoS attacks. While trying to prevent attackers entering the network is good citizenship, the value and effectiveness of the mitigation service increases as you get closer to the target of the attack. In this case there typically aren't very many targets and so a single rule filtering on destination IP address and protocol would typically be effective (and less disruptive to the victim that null routing). > >> Typical networks probably only see a few DDoS attacks an hour at the >> most, so pushing a few rules an hour to mitigate them should have >> little impact on the switch control plane. > > based on what math did you get 'few per hour?' As an endpoint (focal > point) or as a contributor? The problem that started this discussion > was being a contributor...which I bet happens a lot more often than > /few an hour/. I am sorry, I should have been clearer, the SDN solution I was describing is aimed at protecting the target's links, rather than mitigating the botnet and amplification layers. The number of attacks was from the perspective of DDoS targets and their service providers. If you are considering each participant in the attack the number goes up considerably. > >> A good working definition of a large flow is 10% of a link's >> bandwidth. If you only trigger actions for large flows then in the >> worst case you would only require 10 rules per port to change how >> these flows are treated. > > 10% of a 1g link is 100mbps, For contributors to ntp attacks, many of > the contributors are sending ONLY 300x the input, so less than > 100mbps. On a 10g link it's 1G... even more hidden. > > This math and detection aren't HARD, but tuning it can be a bit challenging. Agreed - the technique is less effective for addressing the contributors to the attack. RPF and other edge controls should be applied, but until everyone participates and eliminates attacks at source, there is still a value in filtering close to the target of the attack. > >>>> http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html >>>> >>>> The example can be modified to target NTP mon_getlist requests and >>>> responses using the following sFlow-RT flow definition: >>>> >>>> {'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'} >>>> >>>> or to target DNS ANY requests: >>>> >>>> {keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'} >>>> >>> >>> this also assume almost 1:1 sampling... which might not be feasible >>> either...otherwise you'll be seeing fairly lossy results, right? >> >> Actually, to detect large flows (defined as 10% of link bandwidth) >> within a second, you would only require the following sampling rates: > > your example requires seeing the 1st packet in a cycle, and seeing > into the first packet. that's going to required either acceptance of > loss (and gathering the loss in another rule/fashion) or 1:1 sampling > to be assured of getting ALL of the DNS packets and seeing what was > queried. The flow analysis is stateless - based on a random sample of 1 in N packets, you can decode the packet headers and determine the amount of traffic associated with specific DNS queries. If you are looking at the traffic close to the target, there may be hundreds of thousands of DNS responses per second and so you very quickly determine the target IP address and can apply a filter to remove DNS traffic to that target. > provided your device does sflow and can export to more than one > destination, sure. This brings up an interesting point use case for an OpenFlow capable switch - replicating sFlow, NetFlow, IPFIX, Syslog, SNMP traps etc. Many top of rack switches can also forward the traffic through a GRE/VxLAN tunnel as well. http://blog.sflow.com/2013/11/udp-packet-replication-using-open.html From jtk at cymru.com Mon Feb 3 22:21:34 2014 From: jtk at cymru.com (John Kristoff) Date: Mon, 3 Feb 2014 16:21:34 -0600 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: Message-ID: <20140203162134.698e6d6d@localhost> On Mon, 03 Feb 2014 16:49:37 +1300 Geraint Jones wrote: > We block all outbound UDP for our ~200,000 Users for this very reason > (with the exception of some whitelisted NTP and DNS servers). So far > we have had 0 complaints I've heard this sort of absence of complaint statement used to justify some sort of truth claim about how to operate a network a number of times before. There is a certain appeal to it, particularly in cases such as this and for certain types of networks and operators, but if nothing else, for those that do it, I would also like to see some additional analysis about what is being filtered. It leaves many unconvinced and left to conjecture what the right approach is otherwise. If you have done that analysis or if you could make available some of that data for a research project, it would be very helpful for everyone to see what the measurable effect is. It would also make for a useful research project. John From jtk at cymru.com Mon Feb 3 22:38:43 2014 From: jtk at cymru.com (John Kristoff) Date: Mon, 3 Feb 2014 16:38:43 -0600 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <36E69809-C0B7-497D-A4AA-B251D0C9EA4A@arbor.net> References: <20140202204446.50900.qmail@joyce.lan> <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> <36E69809-C0B7-497D-A4AA-B251D0C9EA4A@arbor.net> Message-ID: <20140203163843.0a55e802@localhost> On Mon, 3 Feb 2014 07:08:25 +0000 "Dobbins, Roland" wrote: > There's nothing in IPv6 which makes any difference. The ultimate > solution is antispoofing at the customer edge. There is at least one small thing that may change some part of this and similar problems. If the threat vector were only accessible on IPv6 and that service on those systems is not easily discoverable then it will probably reduce the total population of systems being abused. I do realize in practice there are ways to discover systems, but the change in address architecture could change things, not perfectly, but I'll venture to suggest noticeably in some not so difficult to imagine scenarios. John From jtowne at slic.com Mon Feb 3 22:42:44 2014 From: jtowne at slic.com (Jonathan Towne) Date: Mon, 3 Feb 2014 17:42:44 -0500 Subject: -48VDC supply for home lab? In-Reply-To: <52F0054C.8030000@garlic.com> References: <52F0054C.8030000@garlic.com> Message-ID: <20140203224244.GH24634@hijacked.us> Tellabs stuff seems to work reasonably well: I've got a model 8001 -48VDC PDU in my lab rack at home, although it only supplies @ 1A, it does a fine enough job for what I need. Have a look at the Tellabs PS-1478 or so, which should do 10A. They're not explicitly rackmountable, but look like they'd easily be adapted to do so. You can still find PDF copies of Tellabs documentation online, too, and I believe the PS-1478 should be floating ground like my 8001. Hint: they can be had cheaply on ebay, since this is a home project, after all. That's where I obtained my 8001. There is still one seller around on ebay selling them for *way less* than $400, used. -- Jonathan Towne On Mon, Feb 03, 2014 at 01:08:28PM -0800, Robert Glover scribbled: # On 2/3/2014 1:02 PM, Mark Leonard wrote: # > Greetings NANOG'ers! # > # > I have a small home lab which I mostly use for learning and testing. I'm # > likely to receive some gear that needs negative 48VDC (ie: positive # > ground). Mains is a typical 120VAC, 60Hz. # > # > Can anyone recommend a power supply, reasonably priced, to go from 120VAC # > down to -48VDC at 10Amps? Something that fits in a two post rack would be # > preferred, but not required. # > # > Thanks, # > Mark # > # # Mark, # # I'd recommend a Kepco PRR 48-22M. We have one in-office, used it for # some -48VDC equipment (Adtran Total Access gear) that we tested # in-office. Worked great, and can be found on eBay for under $400 # # -Bobby # From rdobbins at arbor.net Mon Feb 3 22:55:06 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 3 Feb 2014 22:55:06 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140203163843.0a55e802@localhost> References: <20140202204446.50900.qmail@joyce.lan> <7BB2C9DD-EA22-45EB-A2ED-D4CE6A73FD12@arbor.net> <36E69809-C0B7-497D-A4AA-B251D0C9EA4A@arbor.net> <20140203163843.0a55e802@localhost> Message-ID: <33A83B53-0E9E-4F16-B2F5-17398FA487C2@arbor.net> On Feb 4, 2014, at 5:38 AM, John Kristoff wrote: > I do realize in practice there are ways to discover systems, but the change in address architecture could change things, not perfectly, but I'll venture to suggest noticeably in some not so difficult to imagine > scenarios. I know you're aware of the work in this area, so I'll just note for the record that the 'IPv6 makes scanning impossible!' has already been exploded. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From morrowc.lists at gmail.com Mon Feb 3 22:58:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Feb 2014 17:58:21 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: wait, so the whole of the thread is about stopping participants in the attack, and you're suggesting that removing/changing end-system switch/routing gear and doing something more complex than: deny udp any 123 any deny udp any 123 any 123 permit ip any any is a good plan? I'd direct you at: and particularly at: "Tutorial: ISP Security - Real World Techniques II" On Mon, Feb 3, 2014 at 5:16 PM, Peter Phaal wrote: > On Mon, Feb 3, 2014 at 12:38 PM, Christopher Morrow > wrote: >> On Mon, Feb 3, 2014 at 2:42 PM, Peter Phaal wrote: >>> On Mon, Feb 3, 2014 at 10:16 AM, Christopher Morrow >>> wrote: >>>> On Mon, Feb 3, 2014 at 12:42 PM, Peter Phaal wrote: >> >>>> There's certainly the case that you could drop acls/something on >>>> equipment to selectively block the traffic that matters... I suspect >>>> in some cases the choice was: "50% of the edge box customers on this >>>> location are a problem, block it across the board here instead of X00 >>>> times" (see concern about tcam/etc problems) >>> >>> I agree that managing limited TCAM space is critical to the >>> scaleability of any mitigation solution. However, tying up TCAM space >>> on every edge device with filters to prevent each new threat is likely >> >> yup, there's a tradeoff, today it's being made one way, tomorrow >> perhaps a different way. My point was that today the percentage of sdn >> capable devices is small enough that you still need a decimal point to >> measure it. (I bet, based on total devices deployed) The percentage of >> oss backend work done to do what you want is likely smaller... >> >> the folk in NZ-land (Citylink, reannz ... others - find josh baily / >> cardigan) are making some strides, but only in the exchange areas so >> far. fun stuff... but not the deployed gear as an L2/L3 device in >> TWC/Comcast/Verizon. > > I agree that today most networks aren't SDN ready, but there are > inexpensive switches on the market that can perform these functions > and for providers that have them in their network, this is an option > today. In some environments, it could also make sense to drop in a > layer switches to monitor and control traffic entering / exiting the > network. it's probably not a good plan to forklift your edge, for dos targets where all you really need is a 3 line acl. > >>> The current 10G upgrade cycle provides an opportunity to deploy >> >> by 'current 10g upgrade cycle' you mean the one that happened 2-5 yrs >> ago? or somethign newer? did you mean 100G? > > I was referring to the current upgrade cycle in data centers, with > servers connected with 10G rather than 1G adapters. The high volumes > are driving down the cost of 10/40/100G switches. again, lots of cost and churn for 3 lines of acl... I'm not sold. >>> With integrated hybrid OpenFlow, there is very little activity on the >>> OpenFlow control plane. The normal BGP, ECMP, LAG, etc. control planes >>> handles forwarding of packets. OpenFlow is only used to selectively >>> override specific FIB entries. >> >> that didn't really answer the question :) if I have 10k customers >> behind the edge box and some of them NOW start being abused, then more >> later and that mix changes... if it changes a bunch because the >> attacker is really attackers. how fast do I change before I can't do >> normal ops anymore? > > Good point - the proposed solution is most effective for protecting > customers that are targeted by DDoS attacks. While trying to prevent Oh, so the 3 line acl is not an option? or (for a lot of customers a fine answer) null route? Some things have changed in the world of dos mitigation, but a bunch of the basics still apply. I do know that in the unfortunate event that your network is the transit or terminus of a dos attack at high volume you want to do the least configuration that'll satisfy the 2 parties involved (you and your customer)... doing a bunch of hardware replacement and/or sdn things when you can get the job done with some acls or routing changes is really going to be risky. > attackers entering the network is good citizenship, the value and > effectiveness of the mitigation service increases as you get closer to > the target of the attack. In this case there typically aren't very > many targets and so a single rule filtering on destination IP address > and protocol would typically be effective (and less disruptive to the > victim that null routing). > >> >>> Typical networks probably only see a few DDoS attacks an hour at the >>> most, so pushing a few rules an hour to mitigate them should have >>> little impact on the switch control plane. >> >> based on what math did you get 'few per hour?' As an endpoint (focal >> point) or as a contributor? The problem that started this discussion >> was being a contributor...which I bet happens a lot more often than >> /few an hour/. > > I am sorry, I should have been clearer, the SDN solution I was > describing is aimed at protecting the target's links, rather than > mitigating the botnet and amplification layers. and i'd say that today sdn is out of reach for most deployments, and that the simplest answer is already available. > The number of attacks was from the perspective of DDoS targets and > their service providers. If you are considering each participant in > the attack the number goes up considerably. I bet roland has some good round-numbers on number of dos attacks per day... I bet it's higher than a few per hour globally, for the ones that get noticed. >>> A good working definition of a large flow is 10% of a link's >>> bandwidth. If you only trigger actions for large flows then in the >>> worst case you would only require 10 rules per port to change how >>> these flows are treated. >> >> 10% of a 1g link is 100mbps, For contributors to ntp attacks, many of >> the contributors are sending ONLY 300x the input, so less than >> 100mbps. On a 10g link it's 1G... even more hidden. >> >> This math and detection aren't HARD, but tuning it can be a bit challenging. > > Agreed - the technique is less effective for addressing the > contributors to the attack. RPF and other edge controls should be note that the focus of the original thread was on the contributors. I think the target part of the problem has been solved since before the slides in the pdf link at the top... > applied, but until everyone participates and eliminates attacks at > source, there is still a value in filtering close to the target of the > attack. > >> >>>>> http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html >>>>> >>>>> The example can be modified to target NTP mon_getlist requests and >>>>> responses using the following sFlow-RT flow definition: >>>>> >>>>> {'ipdestination,udpsourceport',value:'ntppvtbytes',filter:'ntppvtreq=20,42'} >>>>> >>>>> or to target DNS ANY requests: >>>>> >>>>> {keys:'ipdestination,udpsourceport',value:'frames',filter:'dnsqr=true&dnsqtype=255'} >>>>> >>>> >>>> this also assume almost 1:1 sampling... which might not be feasible >>>> either...otherwise you'll be seeing fairly lossy results, right? >>> >>> Actually, to detect large flows (defined as 10% of link bandwidth) >>> within a second, you would only require the following sampling rates: >> >> your example requires seeing the 1st packet in a cycle, and seeing >> into the first packet. that's going to required either acceptance of >> loss (and gathering the loss in another rule/fashion) or 1:1 sampling >> to be assured of getting ALL of the DNS packets and seeing what was >> queried. > > The flow analysis is stateless - based on a random sample of 1 in N > packets, you can decode the packet headers and determine the amount of > traffic associated with specific DNS queries. If you are looking at you're getting pretty complicated for the target side: ip access-list 150 permit ip any any log (note this is basically taken verbatim from the slides) view logs, see the overwhelming majority are to hostX port Y proto Z... filter, done. you can do that in about 5 mins time, quicker if you care to rush a bit. > the traffic close to the target, there may be hundreds of thousands of > DNS responses per second and so you very quickly determine the target > IP address and can apply a filter to remove DNS traffic to that > target. > >> provided your device does sflow and can export to more than one >> destination, sure. > > This brings up an interesting point use case for an OpenFlow capable > switch - replicating sFlow, NetFlow, IPFIX, Syslog, SNMP traps etc. > Many top of rack switches can also forward the traffic through a > GRE/VxLAN tunnel as well. yes, more complexity seems like a great plan... in the words of someone else: "I encourage my competitors to do this" I think roland's other point that not very many people actually even use sflow is not to be taken lightly here either. -chris > http://blog.sflow.com/2013/11/udp-packet-replication-using-open.html Domain Name: SFLOW.COM Registry Registrant ID: Registrant Name: PHAAL, PETER Registrant Organization: InMon Corp. From baldur.norddahl at gmail.com Mon Feb 3 23:06:50 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 4 Feb 2014 00:06:50 +0100 Subject: -48VDC supply for home lab? In-Reply-To: References: Message-ID: I am using this: http://www.newark.com/xp-power/jpm160ps48/psu-160w-48v-3-3a/dp/97K2572 Locally it is available here for about $50 USD as new. I found it in a shop selling electronics for disco - don't tell them you are doing networks, that info will multiply the price by 10 :-). Regards, Baldur On 3 February 2014 22:02, Mark Leonard wrote: > Greetings NANOG'ers! > > I have a small home lab which I mostly use for learning and testing. I'm > likely to receive some gear that needs negative 48VDC (ie: positive > ground). Mains is a typical 120VAC, 60Hz. > > Can anyone recommend a power supply, reasonably priced, to go from 120VAC > down to -48VDC at 10Amps? Something that fits in a two post rack would be > preferred, but not required. > > Thanks, > Mark > From will at loopfree.net Tue Feb 4 00:12:27 2014 From: will at loopfree.net (Will Orton) Date: Mon, 3 Feb 2014 16:12:27 -0800 Subject: -48VDC supply for home lab? In-Reply-To: References: Message-ID: <20140204001227.GA24703@loopfree.net> I use: http://www.mastechpowersupply.com/dc-power-supply/switching-power-supply/volteq-power-supply-hy5020ex-50v-20a-over-voltage-over-current-protection/prod_61.html The output is changable from positive to negative ground by moving the shorting bar to ground from the - output to the + side. If you need to be able to charge a 48v battery plant you'd want the 60v version instead, but it's more $. The 50v one works fine for benchtesting equipment, at least. -Will On Mon, Feb 03, 2014 at 02:02:11PM -0700, Mark Leonard wrote: > Date: Mon, 3 Feb 2014 14:02:11 -0700 > Subject: -48VDC supply for home lab? > From: Mark Leonard > To: "North American Network Operators' Group" > > Greetings NANOG'ers! > > I have a small home lab which I mostly use for learning and testing. I'm > likely to receive some gear that needs negative 48VDC (ie: positive > ground). Mains is a typical 120VAC, 60Hz. > > Can anyone recommend a power supply, reasonably priced, to go from 120VAC > down to -48VDC at 10Amps? Something that fits in a two post rack would be > preferred, but not required. > > Thanks, > Mark From gdt at gdt.id.au Tue Feb 4 00:40:35 2014 From: gdt at gdt.id.au (Glen Turner) Date: Tue, 4 Feb 2014 11:10:35 +1030 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: <2FFA5472-37CC-425E-AB9B-470F9DF60FB4@gdt.id.au> On 4 Feb 2014, at 9:28 am, Christopher Morrow wrote: > wait, so the whole of the thread is about stopping participants in the > attack, and you're suggesting that removing/changing end-system > switch/routing gear and doing something more complex than: > deny udp any 123 any > deny udp any 123 any 123 > permit ip any any Which just pushes NTP to some other port, making control harder. We?ve already pushed all ?interesting' traffic to port 80 on TCP, which has made traffic control very expensive. Let?s not repeat that history. -- Glen Turner From peter.phaal at gmail.com Tue Feb 4 00:54:40 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 3 Feb 2014 16:54:40 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: On Mon, Feb 3, 2014 at 2:58 PM, Christopher Morrow wrote: > wait, so the whole of the thread is about stopping participants in the > attack, and you're suggesting that removing/changing end-system > switch/routing gear and doing something more complex than: > deny udp any 123 any > deny udp any 123 any 123 > permit ip any any > > is a good plan? > > I'd direct you at: > > > and particularly at: > "Tutorial: ISP Security - Real World Techniques II" > Thanks for the links. Many SDN solutions can be replicated using manual processes (or are ways of automating currently manual processes). Programmatic APIs allows the speed and accuracy of the response to be increased and the solution to be delivered at scale and at lower cost. > it's probably not a good plan to forklift your edge, for dos targets > where all you really need is a 3 line acl. For many networks it doesn't need to be forklift upgrade - vendors are adding programmatic APIs to their existing products (OpenFlow, Arista eAPI, NETCONF, ALU Web Services ...) - so a firmware upgrade may be all that is required. I do think that there are operational advantages to using protocols like OpenFlow, I2RS, BGP FlowSpec for these soft controls since they allow the configuration to remain relatively static and they avoid problems of split control (for example, and operator makes a config change and saves, locking in a temporary control from the SDN system). I would argue that the more specific the ACL can be the less collateral damage. Built-in measurement allows for a more targeted response. >> Good point - the proposed solution is most effective for protecting >> customers that are targeted by DDoS attacks. While trying to prevent > > Oh, so the 3 line acl is not an option? or (for a lot of customers a > fine answer) null route? Some things have changed in the world of dos > mitigation, but a bunch of the basics still apply. I do know that in > the unfortunate event that your network is the transit or terminus of > a dos attack at high volume you want to do the least configuration > that'll satisfy the 2 parties involved (you and your customer)... > doing a bunch of hardware replacement and/or sdn things when you can > get the job done with some acls or routing changes is really going to > be risky. I think an automatic system using a programmatic API to install as narrowly scoped a filter as possible is the most conservative and least risky option. Manual processes are error prone, slow, and blunt instruments like a null route can cause collateral damage to services. >>>> Typical networks probably only see a few DDoS attacks an hour at the >>>> most, so pushing a few rules an hour to mitigate them should have >>>> little impact on the switch control plane. >>> >>> based on what math did you get 'few per hour?' As an endpoint (focal >>> point) or as a contributor? The problem that started this discussion >>> was being a contributor...which I bet happens a lot more often than >>> /few an hour/. >> >> I am sorry, I should have been clearer, the SDN solution I was >> describing is aimed at protecting the target's links, rather than >> mitigating the botnet and amplification layers. > > and i'd say that today sdn is out of reach for most deployments, and > that the simplest answer is already available. > >> The number of attacks was from the perspective of DDoS targets and >> their service providers. If you are considering each participant in >> the attack the number goes up considerably. > > I bet roland has some good round-numbers on number of dos attacks per > day... I bet it's higher than a few per hour globally, for the ones > that get noticed. The "few per hour" number isn't a global statistic. This is the number that a large hosting data center might experience. The global number is much larger, but not very relevant to a specific provider looking to size a mitigation solution. > note that the focus of the original thread was on the contributors. I > think the target part of the problem has been solved since before the > slides in the pdf link at the top... Do most service providers allow their customers to control ACLs in the upstream routers? Do they automatically monitor traffic and insert the filters themselves when there is an attack? I don't believe so - while the slides describe a solution, automation is needed to make available at large scale. > you're getting pretty complicated for the target side: > ip access-list 150 permit ip any any log > > (note this is basically taken verbatim from the slides) > > view logs, see the overwhelming majority are to hostX port Y proto > Z... filter, done. > you can do that in about 5 mins time, quicker if you care to rush a bit. An automated system can perform the analysis and apply the filter in a second with no human intervention. What if you have to manage thousands of customer links? >> This brings up an interesting point use case for an OpenFlow capable >> switch - replicating sFlow, NetFlow, IPFIX, Syslog, SNMP traps etc. >> Many top of rack switches can also forward the traffic through a >> GRE/VxLAN tunnel as well. > > yes, more complexity seems like a great plan... in the words of > someone else: "I encourage my competitors to do this" Using the existing switches to replicate and tap production traffic is less complex and more scalable than alternatives. You may find the following use case interesting: http://blog.sflow.com/2013/04/sdn-packet-broker.html > I think roland's other point that not very many people actually even > use sflow is not to be taken lightly here either. It doesn't have to be sFlow - the sFlow solution was provided as a concrete example since that is the technology I am most familiar with. However, sFlow, IPFIX, NetFlow, jFlow etc. combined with analytics and a programmatic control API allows DDoS mitigation to be automated. I think Roland would agree that an automated response is more effective than a manual process. From msa at latt.net Tue Feb 4 01:10:01 2014 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 3 Feb 2014 20:10:01 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <52EFEC54.2060905@Opus1.COM> Message-ID: <20140204011001.GA8350@puck.nether.net> On Mon, Feb 03, 2014 at 03:50:03PM -0500, John R. Levine wrote: > I believe you, but I don't believe that the set of ntp.org servers > changes so rapidly that it is beyond the ability of network > operators to handle the ones on their own networks as a special > case. I think you'd be surprised. I have to say I've been shocked at how little most network operators appear to understand about how NTP actually works, and how little thought is going into the consequences of suggested filtering techniques. Has anyone considered the implications of a world where your customers cannot correlate timestamps on abuse reports because you decided you knew better than they did how, and which sources of time they would be allowed to use? NTP works best with a diverse set of peers. You know, outside your little bubble, or walled garden, or whatever people in this thread appear to be trying to build. I'm not sure what to call it, but it's definitely not the Internet. --msa From cb.list6 at gmail.com Tue Feb 4 01:50:11 2014 From: cb.list6 at gmail.com (Cb B) Date: Mon, 3 Feb 2014 17:50:11 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <52EFDE87.2050307@mykolab.com> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EFDE87.2050307@mykolab.com> Message-ID: On Feb 3, 2014 10:23 AM, "Paul Ferguson" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2/2/2014 2:17 PM, Cb B wrote: > > > And, i agree bcp38 would help but that was published 14 years ago. > > But what? Are you somehow implying that because BCP38 was > "...published 14 years ago" (RFC2267 was initially published in 1998, > and it was subsequently replaced by RFC2827)? > > I hope not, because BCP38 filtering would still help stop spoofed > traffic now perpetuating these attacks, 14 years after BCP38 was > published, because spoofing is at the root of this problem > (reflection/amplification attacks). > > This horse is not dead, and still deserves a lot of kicking. > > $.02, > > - - ferg (co-author of BCP38) > I completely agree. My sphere of influence is bcp38 compliant. And, networks that fail to support some form of bcp38 are nothing short of negligent. That said, i spend too much time taking defensive action against ipv4 amp udp attacks. And wishing others would deploy bcp38 does not solve today's ddos attacks. CB > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlLv3ocACgkQKJasdVTchbLhowEAuO9DSQiRswVeqpHSccHo060h > cqmIB8XlaNkzEPQw1w0A/0G6cjvtWBiJfwWbWoTY7X3RRMHeN36RkYR+2TonyNBi > =W2wU > -----END PGP SIGNATURE----- From morrowc.lists at gmail.com Tue Feb 4 02:13:06 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Feb 2014 21:13:06 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <2FFA5472-37CC-425E-AB9B-470F9DF60FB4@gdt.id.au> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> <2FFA5472-37CC-425E-AB9B-470F9DF60FB4@gdt.id.au> Message-ID: On Mon, Feb 3, 2014 at 7:40 PM, Glen Turner wrote: > > On 4 Feb 2014, at 9:28 am, Christopher Morrow wrote: > >> wait, so the whole of the thread is about stopping participants in the >> attack, and you're suggesting that removing/changing end-system >> switch/routing gear and doing something more complex than: >> deny udp any 123 any >> deny udp any 123 any 123 >> permit ip any any > > Which just pushes NTP to some other port, making control harder. We've already pushed all 'interesting' traffic to port 80 on TCP, which has made traffic control very expensive. Let's not repeat that history. I think in the case of 'oh crap, customer is getting 100gbps of ntp...' the above (a third party notes that the 2nd line is redundant) is a fine answer, till the flood abates. I wouldn't recommend wholesale blocking of anything across an ISP edge, but for the specific case paul was getting at: "ntp reflection attack target is your customer" ... it's going to solve the problem. From morrowc.lists at gmail.com Tue Feb 4 02:33:51 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Feb 2014 21:33:51 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: -larry directly since I'm sure he's either tired of this, or already reading it via the nanog subscription. On Mon, Feb 3, 2014 at 7:54 PM, Peter Phaal wrote: > On Mon, Feb 3, 2014 at 2:58 PM, Christopher Morrow > wrote: >> wait, so the whole of the thread is about stopping participants in the >> attack, and you're suggesting that removing/changing end-system >> switch/routing gear and doing something more complex than: >> deny udp any 123 any >> deny udp any 123 any 123 >> permit ip any any >> >> is a good plan? >> >> I'd direct you at: >> >> >> and particularly at: >> "Tutorial: ISP Security - Real World Techniques II" >> > > Thanks for the links. Many SDN solutions can be replicated using you're sort of a broken record on this bit ... I don't think folk are (me in particular) knocking sdn things, in general. In the specific though: 1) you missed the point originally, stop marketing your blog pls. 2) you missed the point(s) about availability and realistic deployment of solutions in the near term > manual processes (or are ways of automating currently manual > processes). Programmatic APIs allows the speed and accuracy of the > response to be increased and the solution to be delivered at scale and > at lower cost. and all of these require very strict and very careful deployment of oss measures to watch over current state and intended state. They require also very careful training and troubleshooting steps for the ops folk running the systems. None of this is deployable 'tomorrow' (in under 24hrs) safely, and most likely it'll be a bit more time until there is ubiquitous deployment of sdn-like functionality in larger scale networks. not that I'm not a fan, and not that I don't like me some automation, but.. having seen automation go very wrong (l3's acl spider... crushes l3..., flowspec 'whoopsie' at cloudflare and TWTC... there are lots of other examples). >> it's probably not a good plan to forklift your edge, for dos targets >> where all you really need is a 3 line acl. > > For many networks it doesn't need to be forklift upgrade - vendors are > adding programmatic APIs to their existing products (OpenFlow, Arista > eAPI, NETCONF, ALU Web Services ...) - so a firmware upgrade may be arista is deployed in which large scale networks with api/sdn functionality ? they're a great bunch of folks, they make some nice gear, it's still getting baked though, and it's not displacing (today) existing gear that's still being depreciated. for anything to be workable in the near-term, the above examples just aren't going to work. note my many references to "5-7 yrs when deprecation cycles and next-replacement happens" > all that is required. > > I do think that there are operational advantages to using protocols > like OpenFlow, I2RS, BGP FlowSpec for these soft controls since they > allow the configuration to remain relatively static and they avoid > problems of split control (for example, and operator makes a config > change and saves, locking in a temporary control from the SDN system). automation, with protections, safety checks, assurances that the process won't break things in odd failure modes.. not to mention bug^H^H^Hfeature issues with gear, we're still a bit from large scale deployment. > I would argue that the more specific the ACL can be the less > collateral damage. Built-in measurement allows for a more targeted > response. sure, I think roland and I at least have been saying the same thing. >>> Good point - the proposed solution is most effective for protecting >>> customers that are targeted by DDoS attacks. While trying to prevent >> >> Oh, so the 3 line acl is not an option? or (for a lot of customers a >> fine answer) null route? Some things have changed in the world of dos >> mitigation, but a bunch of the basics still apply. I do know that in >> the unfortunate event that your network is the transit or terminus of >> a dos attack at high volume you want to do the least configuration >> that'll satisfy the 2 parties involved (you and your customer)... >> doing a bunch of hardware replacement and/or sdn things when you can >> get the job done with some acls or routing changes is really going to >> be risky. > > I think an automatic system using a programmatic API to install as > narrowly scoped a filter as possible is the most conservative and > least risky option. Manual processes are error prone, slow, and blunt > instruments like a null route can cause collateral damage to services. folk say this, but the customer very often explicitly asks for null routes. The thing being targetted is very often not 'revenue generating ecommerce site', and for providers where the default answer is 'everything is a null route', their customers ought to find a provider that thinks differently. >>>>> Typical networks probably only see a few DDoS attacks an hour at the >>>>> most, so pushing a few rules an hour to mitigate them should have >>>>> little impact on the switch control plane. >>>> >>>> based on what math did you get 'few per hour?' As an endpoint (focal >>>> point) or as a contributor? The problem that started this discussion >>>> was being a contributor...which I bet happens a lot more often than >>>> /few an hour/. >>> >>> I am sorry, I should have been clearer, the SDN solution I was >>> describing is aimed at protecting the target's links, rather than >>> mitigating the botnet and amplification layers. >> >> and i'd say that today sdn is out of reach for most deployments, and >> that the simplest answer is already available. >> >>> The number of attacks was from the perspective of DDoS targets and >>> their service providers. If you are considering each participant in >>> the attack the number goes up considerably. >> >> I bet roland has some good round-numbers on number of dos attacks per >> day... I bet it's higher than a few per hour globally, for the ones >> that get noticed. > > The "few per hour" number isn't a global statistic. This is the number > that a large hosting data center might experience. The global number I wonder how many rackspace, softlayer, amazon-aws, xs4all, hetzner, etc experience per hour. in any case, 'often' is probably close enough. > is much larger, but not very relevant to a specific provider looking > to size a mitigation solution. > >> note that the focus of the original thread was on the contributors. I >> think the target part of the problem has been solved since before the >> slides in the pdf link at the top... > > Do most service providers allow their customers to control ACLs in the > upstream routers? Do they automatically monitor traffic and insert the nope, and I don't necessarily think that changes with SDN... letting your customer traffic-engineer is ... dangerous. it tosses capacity planning concerns out the window :( There are several providers, however, that let their customers initiate smart/intelligent mitigation solutions though. I know of 3 that let the customer trigger based on BGP community. A customer can choose how they want to 'detect' and then simply bgp-update for mitigation... I bet there are folk that don't own networks that provide this service as well... I'm sure roland has some work stories he's presented on about this very thing. > filters themselves when there is an attack? I don't believe so - while some providers do, based upon customer demand for the service. it's not really that hard, though it is a cost for the provider so that's shared with the customers using the solution(s). > the slides describe a solution, automation is needed to make available > at large scale. automation isn't precluded from solution space in the slides, note that they were presented and created in ~2002... so the state of the art has changed a bit since then, but the methodology and practices from 2002 can be applied fairly directly today. >> you're getting pretty complicated for the target side: >> ip access-list 150 permit ip any any log >> >> (note this is basically taken verbatim from the slides) >> >> view logs, see the overwhelming majority are to hostX port Y proto >> Z... filter, done. >> you can do that in about 5 mins time, quicker if you care to rush a bit. > > An automated system can perform the analysis and apply the filter in a > second with no human intervention. What if you have to manage > thousands of customer links? been there, done that... got several tshirts. it's honestly not that bad. >>> This brings up an interesting point use case for an OpenFlow capable >>> switch - replicating sFlow, NetFlow, IPFIX, Syslog, SNMP traps etc. >>> Many top of rack switches can also forward the traffic through a >>> GRE/VxLAN tunnel as well. >> >> yes, more complexity seems like a great plan... in the words of >> someone else: "I encourage my competitors to do this" > > Using the existing switches to replicate and tap production traffic is > less complex and more scalable than alternatives. You may find the > following use case interesting: > > http://blog.sflow.com/2013/04/sdn-packet-broker.html > >> I think roland's other point that not very many people actually even >> use sflow is not to be taken lightly here either. > > It doesn't have to be sFlow - the sFlow solution was provided as a > concrete example since that is the technology I am most familiar with. and which, according to a credible source, is not deployed by and large by service providers. certainly in some IDC situations sflow is interesting, but it's not there according to someone who I believe is in a position to know, for isp situations. leaving it out though, some signal of 'traffic looks like' is available if deployed. not everyone does...some don't because 'meh!' some don't because 'not in featureset bought' some don't because ''. folk that don't have it generally can't just crank it up 'now' though. > However, sFlow, IPFIX, NetFlow, jFlow etc. combined with analytics and > a programmatic control API allows DDoS mitigation to be automated. I right, arbor sells this, as one example. (there are others of course) there are several large US isp's that use that solution (or an offspring of that) today. it's not quite sdn, but it is automated and relatively fire/forget. -chris From jra at baylink.com Tue Feb 4 03:23:22 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 3 Feb 2014 22:23:22 -0500 (EST) Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: Message-ID: <23822783.7058.1391484202270.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Cb B" > I completely agree. My sphere of influence is bcp38 compliant. And, > networks that fail to support some form of bcp38 are nothing short of > negligent. > > That said, i spend too much time taking defensive action against ipv4 amp > udp attacks. And wishing others would deploy bcp38 does not solve today's > ddos attacks. Nope. But providing a bigger, better tuned hammer to apply to people's heads may. So any contributions you can make to http://www.bcp38.info will be cheerfully accepted. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mike-nanog at tiedyenetworks.com Tue Feb 4 05:34:52 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 03 Feb 2014 21:34:52 -0800 Subject: looking for a tool... Message-ID: <52F07BFC.6010502@tiedyenetworks.com> Hello, I was wondering if anyone could point me in the direction of a tool capable of sniffing (or reading pcap files), and reporting on lan station thruput in terms of bits per second. Ideally I'd like to be able to generate a sorted report of the top users and top thruputs observed and so forth. The traffic is pppoe and I need to monitor it at a specific switchport where I can arrange span. Thank you. From andre at operations.net Tue Feb 4 05:39:14 2014 From: andre at operations.net (Andre Gironda) Date: Tue, 4 Feb 2014 08:39:14 +0300 Subject: looking for a tool... In-Reply-To: <52F07BFC.6010502@tiedyenetworks.com> References: <52F07BFC.6010502@tiedyenetworks.com> Message-ID: Similar discussion not long ago mentioned tcptrace.org dre ---------- Forwarded message ---------- From: Andre Gironda Date: Mon, Feb 3, 2014 at 9:05 PM Subject: Re: Do network diagnostic tools need upgrade? To: "nanog at nanog.org" Cc: Ammar Salih Oldies, but goodies: shaperprobe (1st), pchar (3rd), tcptrace.org, lft (4th), iftop, nsping (2nd), iperf, sjitter, pathneck (3rd) These are newer -- http://www.internet2.edu/products-services/performance-monitoring/performance-tools/(OWAMP, 2nd) -- http://paris-traceroute.net (4th) -- http://packetdrill.googlecode.com dre On Mon, Feb 3, 2014 at 4:33 PM, Ammar Salih wrote: Hello NANOG list members, I have a question for you, are you happy with the current network diagnostic tools, like ping, trace route .. etc, don't you think it's time to have an upgraded version of icmp protocol? from my side there is a lot that I can NOT do with current tools and protocols, here are few scenarios, and I would like to hear yours: First scenario: To be able to troubleshoot advanced networks with complex QoS and policy-based routing configuration, where ping, traceroute and other network diagnostic tools do not provide accurate readings, for example, you are troubleshooting a web server with ping, and it looks functioning quite well (packet loss and round trip time is all good), but web services are still significantly slow, the fact is icmp and tcp:80 might have different priorities and bandwidth limits on each router along the path between the client and the server, in this case, network admins usually use telnet applications like (Paping), well it may help if the forward and return path of all packets are exactly the same. Second scenario: So another possible scenario is that you need to determine readings for forward and return paths, TraceRoute for example gives you forward path only using icmp. But what if you need to troubleshoot a VoIP server for example, assuming that packets return path might not be the same as forward path. Third scenario: One of the most common problems in networking, is that you don't have access to all equipment between client and server, but you have to troubleshoot the path between them and to understand where the problem exactly is in order to contact the right person without having the privilege to check the configuration on each router. Fourth scenario: Also, with trace route you can't determine the actual path, for example, the router may direct http traffic to proxy server while leaving other traffic going through a different hop. On Tue, Feb 4, 2014 at 8:34 AM, Mike wrote: > Hello, > > I was wondering if anyone could point me in the direction of a tool > capable of sniffing (or reading pcap files), and reporting on lan station > thruput in terms of bits per second. Ideally I'd like to be able to > generate a sorted report of the top users and top thruputs observed and so > forth. The traffic is pppoe and I need to monitor it at a specific > switchport where I can arrange span. > > Thank you. > > > From jra at baylink.com Tue Feb 4 05:52:48 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Feb 2014 00:52:48 -0500 (EST) Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <2FFA5472-37CC-425E-AB9B-470F9DF60FB4@gdt.id.au> Message-ID: <10381881.7188.1391493168316.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Glen Turner" > On 4 Feb 2014, at 9:28 am, Christopher Morrow > wrote: > > > wait, so the whole of the thread is about stopping participants in > > the attack, and you're suggesting that removing/changing end-system > > switch/routing gear and doing something more complex than: > > deny udp any 123 any > > deny udp any 123 any 123 > > permit ip any any > > Which just pushes NTP to some other port, making control harder. We?ve > already pushed all ?interesting' traffic to port 80 on TCP, which has > made traffic control very expensive. Let?s not repeat that history. "Those who do not understand the Internet are condemned to reinvent it. Poorly." -- after henry at utzoo, though he was talking about Unix, and I am generally looking at Tapatalk and talking about Usenet. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From dougb at dougbarton.us Tue Feb 4 06:29:15 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 03 Feb 2014 22:29:15 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140204011001.GA8350@puck.nether.net> References: <52EFEC54.2060905@Opus1.COM> <20140204011001.GA8350@puck.nether.net> Message-ID: <52F088BB.2010202@dougbarton.us> On 02/03/2014 05:10 PM, Majdi S. Abbas wrote: > NTP works best with a diverse set of peers. You know, outside > your little bubble, or walled garden, or whatever people in this thread > appear to be trying to build. I'm not sure what to call it, but it's > definitely not the Internet. "The Internet" is increasingly becoming something we want someone else to implement so that we can exploit it. Doug From adam.vitkovsky at swan.sk Tue Feb 4 12:56:08 2014 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Tue, 4 Feb 2014 13:56:08 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> Message-ID: <006001cf21a8$790a1540$6b1e3fc0$@swan.sk> > However, a good engineer would know there are drawbacks to next-hop-self, > in particular it slows convergence in a number of situations. > There are networks where fast convergence is more important than route > scaling, and thus the traditional design of BGP next-hops being edge interfaces, > and edge interfaces in the IGP performs better. Well it's not true anymore BGP PIC edge and core converges under 50ms. "fast external failover" and "local repair" where available long before -but yes that's applicable only for MPLS. adam -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, January 15, 2014 3:18 PM To: Dobbins, Roland Cc: NANOG list Subject: Re: best practice for advertising peering fabric routes On Jan 15, 2014, at 12:02 AM, "Dobbins, Roland" wrote: > Again, folks, this isn't theoretical. When the particular attacks cited in this thread were taking place, I was astonished that the IXP infrastructure routes were even being advertised outside of the IXP network, because of these very issues. I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale. However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better. By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone. I don't like a world where connecting to an exchange point forces a particular network design on participants. > IXPs are not the problem when it comes to breaking PMTU-D. The problem is largely with enterprise networks, and with 'security' vendors who've propagated the myth that simply blocking all ICMP somehow increases 'security'. That's some circular reasoning. Networks won't 9K peer at exchange points for a number of reasons, including PMTU-D discovery issues. Since there are virtual no 9K peering at exchange points, PMTU-D is a non-issue. Maybe if IXP design didn't break PMTU-D it would help attract more 9K peers, or there might even be a future where 9K peering was required? This whole problem smacks to me of exchange points that are "too big to fail". Since some of these exchanges are so big, everyone else must bend to their needs. I think the world would be a better place if some of these were broken up into smaller exchanges and they imposed less restrictions on their participants. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From adam.vitkovsky at swan.sk Tue Feb 4 13:10:05 2014 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Tue, 4 Feb 2014 14:10:05 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> Message-ID: <006b01cf21aa$6c19c9a0$444d5ce0$@swan.sk> > But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end. > Customers could then buy a VPN appliance and manage their own VPN's > with no vendor lock-in. MPLS VPN revenues would tumble, and customers > would move more fluidly between providers. That's terrible if you're an ISP. No it's exactly why some carriers do their best to provide 9K+ MTU to most of their POPs so that they can provide L2 services to ISPs and other carriers that require 9K MTU for their BB links to capitalize on these new emerging markets. Customers locked in to a single provider (MPLS VPN) can rely on certain class of service (predictable delay, jitter and packet loss) properties you can't get out of a pure internet connection from NY to Tokyo. adam -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, January 15, 2014 4:31 PM To: Dobbins, Roland Cc: NANOG list Subject: Re: best practice for advertising peering fabric routes On Jan 15, 2014, at 8:49 AM, "Dobbins, Roland" wrote: > Not really. What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison. I think we're looking at two different aspects of the same issue. I believe you're coming at it from a 'for all users of the Internet, what's the chance they have connectivity that does not break PMTU-D.' That's an important group to study, particularly for those DSL users still left with < 1500 byte MTU's. And you're right, for those users IXP's are the least of their worries, mostly it's content-side poor networking, like load balancers and firewalls that don't work correctly. I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I'm the network guy who wants to buy transit in the US, and transit in Germany and run a tunnel of 1500 byte packets end to end, necessitating a ~1540 byte packet. Finding transit providers who will configure jumbo frames is trivial these days, and most backbones are jumbo frame clean (at least to 4470, but many to 9K). There's probably about a 25% chance private peelings are also jumbo clean. Pretty much the only thing broken for this use case is IXP's. Only a few have a second VLAN for 9K peerings, and most participants don't use it for a host of reasons, including PMTU-D problems. I'm an oddball. I think MPLS VPN's are a terrible idea for the consumer, locking them into a single provider in the vast majority of cases. Consumers would be better served by having a tunnel box (IPSec maybe?) at their edge and running there own tunnel over IP provider-independently, if they could get > 1500B MTU at the edge, and move those packets end to end. While I've always thought that, in the post-Snowden world I think I seem a little less crazy, rather than relying on your provider to keep your "VPN" traffic secret, customers should be encrypting it in a device they own. But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end. Customers could then buy a VPN appliance and manage their own VPN's with no vendor lock-in. MPLS VPN revenues would tumble, and customers would move more fluidly between providers. That's terrible if you're an ISP. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From jhall at futuresouth.us Tue Feb 4 08:58:04 2014 From: jhall at futuresouth.us (Jonathan Hall) Date: Tue, 4 Feb 2014 08:58:04 +0000 Subject: looking for a tool... In-Reply-To: <52F07BFC.6010502@tiedyenetworks.com> Message-ID: Have you considered wireshark or Ettercap? I?m not entirely certain they?ll monitor the throughput, but I know they can open PCAP's? Jon On 2/3/14, 11:34 PM, "Mike" wrote: >Hello, > > I was wondering if anyone could point me in the direction of a tool >capable of sniffing (or reading pcap files), and reporting on lan >station thruput in terms of bits per second. Ideally I'd like to be able >to generate a sorted report of the top users and top thruputs observed >and so forth. The traffic is pppoe and I need to monitor it at a >specific switchport where I can arrange span. > >Thank you. > > From rwebb at ropeguru.com Tue Feb 4 13:57:31 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 04 Feb 2014 08:57:31 -0500 Subject: looking for a tool... Message-ID: I suggest wireshark also. Not realtime for throughput, but will open pcap files and you can then get the throughput metrics. Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Jonathan Hall Date:02/04/2014 8:49 AM (GMT-05:00) To: Mike ,nanog at nanog.org Subject: Re: looking for a tool... From vristevs at ramapo.edu Tue Feb 4 14:01:06 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 04 Feb 2014 09:01:06 -0500 Subject: looking for a tool... In-Reply-To: <52F07BFC.6010502@tiedyenetworks.com> References: <52F07BFC.6010502@tiedyenetworks.com> Message-ID: <52F0F2A2.3030406@ramapo.edu> NTOP can do this is in real time. I believe Wireshark will also do what you are looking for. You can capture and analyze or open a .pcap file and analyze. I'm my version, you would do it be going to the following menu: Statistics --> Endpoints On 2/4/2014 12:34 AM, Mike wrote: > Hello, > > I was wondering if anyone could point me in the direction of a > tool capable of sniffing (or reading pcap files), and reporting on lan > station thruput in terms of bits per second. Ideally I'd like to be > able to generate a sorted report of the top users and top thruputs > observed and so forth. The traffic is pppoe and I need to monitor it > at a specific switchport where I can arrange span. > > Thank you. > > -- Vlad From brak at gameservers.com Tue Feb 4 14:02:24 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 04 Feb 2014 09:02:24 -0500 Subject: looking for a tool... In-Reply-To: <52F07BFC.6010502@tiedyenetworks.com> References: <52F07BFC.6010502@tiedyenetworks.com> Message-ID: <52F0F2F0.90304@gameservers.com> pmacct On 2/4/2014 12:34 AM, Mike wrote: > Hello, > > I was wondering if anyone could point me in the direction of a > tool capable of sniffing (or reading pcap files), and reporting on lan > station thruput in terms of bits per second. Ideally I'd like to be > able to generate a sorted report of the top users and top thruputs > observed and so forth. The traffic is pppoe and I need to monitor it > at a specific switchport where I can arrange span. > > Thank you. > > From ikiris at gmail.com Tue Feb 4 15:13:46 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 4 Feb 2014 09:13:46 -0600 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52F088BB.2010202@dougbarton.us> References: <52EFEC54.2060905@Opus1.COM> <20140204011001.GA8350@puck.nether.net> <52F088BB.2010202@dougbarton.us> Message-ID: On the contrary, I encourage all competitors to block protocols indiscriminately, especially ipv4 UDP. Nothing bad could ever come of that! -Blake On Tue, Feb 4, 2014 at 12:29 AM, Doug Barton wrote: > On 02/03/2014 05:10 PM, Majdi S. Abbas wrote: > >> NTP works best with a diverse set of peers. You know, outside >> your little bubble, or walled garden, or whatever people in this thread >> appear to be trying to build. I'm not sure what to call it, but it's >> definitely not the Internet. >> > > "The Internet" is increasingly becoming something we want someone else to > implement so that we can exploit it. > > Doug > > > From bill at herrin.us Tue Feb 4 16:04:08 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 11:04:08 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: On Sun, Feb 2, 2014 at 5:17 PM, Cb B wrote: > And, i agree bcp38 would help but that was published 14 years ago. Howdy, If just three of the transit-free networks rewrote their peering contracts such that there was a $10k per day penalty for sending packets with source addresses the peer should reasonably have known were forged, this problem would go away in a matter of weeks. Granted it would also be helpful to have a BGP extension signifying allowed-source-but-don't-route so that RP filtering would work even when multihomed. Still, even without automatic RP filtering we're capable of preventing spoofed packets if financially incentivized. Thing is, they can't be the source of the solution until they stop being part of the problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Tue Feb 4 16:23:36 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 4 Feb 2014 11:23:36 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> On Feb 4, 2014, at 11:04 AM, William Herrin wrote: > On Sun, Feb 2, 2014 at 5:17 PM, Cb B wrote: >> And, i agree bcp38 would help but that was published 14 years ago. > > Howdy, > > If just three of the transit-free networks rewrote their peering > contracts such that there was a $10k per day penalty for sending > packets with source addresses the peer should reasonably have known > were forged, this problem would go away in a matter of weeks. Granted > it would also be helpful to have a BGP extension signifying > allowed-source-but-don't-route so that RP filtering would work even > when multihomed. Still, even without automatic RP filtering we're > capable of preventing spoofed packets if financially incentivized. > > Thing is, they can't be the source of the solution until they stop > being part of the problem. I?ve seen similar comments in other forums. We are all generally paid for moving packets, not filtering them. The speed at which you can forward packets can often cause increased $$. Using these features also impacts performance, so the cost may actually be 2x in capex+opex to provision ports due to reduced line-rate capability. Even if you take a RPSL-IRR approach to building filters, and even if the router can handle such long ACLs bug-free, you have some objects that expand to cover 50-90% of the internet. They may be someones backup route at some point because of ?something?. Clearly putting the filters as close to the source is helpful but detecting the actual spoofed packet is hard. Take the thread from last-week about how I can detect folks that are allowed to ?spoof?, or ?forward?/?rewrite? my packet destination. Even if it goes over GRE to somewhere, that IP should only be sourced from *my* host. At some point the rest of the trust comes into play that the IP is correct. Too many devices are generous in what they accept and allows these types of attack surfaces to be abused. Until you find yourself on the receiving end of these types of things, you may not ask for or pay for DDoS protection services, or advanced filtering, or even ask your vendor to support these features. I have to wait months for fixes in the features because no support from others in the industry on the platform, etc. Those that are up in arms about this stuff seem to not be the ones asking the vendors for features and fixes. - Jared From Lee at asgard.org Tue Feb 4 16:42:52 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 04 Feb 2014 11:42:52 -0500 Subject: Updated ARIN allocation information In-Reply-To: References: Message-ID: On 1/29/14 5:01 PM, "Leslie Nobile" wrote: > >ARIN would like to share two items of information that may be of interest >to the community. > >First, ARIN has recently begun to issue address space from its last >contiguous /8, 104.0.0.0 /8. The minimum allocation size for this /8 >will be a /24. You may wish to adjust any filters you have in place >accordingly. I was surprised that ARIN started issuing from this /8. I thought it still had a /9 and a /10 in inventory. > >Additionally, ARIN has placed 23.128.0.0/10 in its reserves in >accordance with the policy "Dedicated IPv4 block to facilitate IPv6 >Deployment" (NRPM 4.10). There have been no allocations made from this >block as of yet, however, once we do begin issuing from this block, the >minimum allocation size for this /10 will be a /28 and the maximum >allocation size will be a /24. You may wish to adjust any filters you >have in place accordingly. I see the note at https://www.arin.net/resources/request/ipv4_countdown.html that this block is not included in inventory. Thanks for that. Lee From bill at herrin.us Tue Feb 4 16:52:34 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 11:52:34 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> Message-ID: On Tue, Feb 4, 2014 at 11:23 AM, Jared Mauch wrote: > On Feb 4, 2014, at 11:04 AM, William Herrin wrote: >> If just three of the transit-free networks rewrote their peering >> contracts such that there was a $10k per day penalty for sending >> packets with source addresses the peer should reasonably have known >> were forged, this problem would go away in a matter of weeks. > I've seen similar comments in other forums. We are all generally paid > for moving packets, not filtering them. The speed at which you can forward > packets can often cause increased $$. Using these features also impacts > performance, so the cost may actually be 2x in capex+opex to provision ports > due to reduced line-rate capability. Hi Jared, You're gonna need a bigger TCAM, but even so I think you're overstating the case. > Even if you take a RPSL-IRR approach to building filters, and even if the router > can handle such long ACLs bug-free, you have some objects that expand to > cover 50-90% of the internet. They may be someones backup route at some > point because of 'something'. Yes, but that's OK. In order to make sure that they're aren't originating from the penalizing 10%, your peers will have to implement similar filtering downstream... where the breadth isn't 90%. > Clearly putting the filters as close to the source is helpful but detecting the > actual spoofed packet is hard. At the customer boundary it's trivial: they'll tell you what they originate, and that's what you'll allow. If your customer lies, pass the penalty forward. At the peering boundary, you don't have to detect the forged packets. You can wait until someone complains, confirm it, and then apply the penalty. Packets coming from your peers won't go to your other peers, only to your customers. That's how you rigged your routing. More, evidence that the downstream was authorized to send those packets refutes the penalty. > Until you find yourself on the receiving end of these types of things, you may not > ask for or pay for DDoS protection services, or advanced filtering, or even ask > your vendor to support these features. I have to wait months for fixes in the > features because no support from others in the industry on the platform, etc. DDoS is a bigger problem than spoofing and amplification. My suggestion only addresses spoofing and amplification, not botnets in general. > Those that are up in arms about this stuff seem to not be the ones asking > the vendors for features and fixes. Like I said, the "tier 1's" can't be the source of the solution until they stop being part of the problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Tue Feb 4 18:03:04 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 4 Feb 2014 13:03:04 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> Message-ID: <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> > On Feb 4, 2014, at 11:52 AM, William Herrin wrote: > > > >> Those that are up in arms about this stuff seem to not be the ones asking >> the vendors for features and fixes. > > Like I said, the "tier 1's" can't be the source of the solution until > they stop being part of the problem. This is the attitude that I've seen elsewhere that is devoid of any meat. As I said before, we hit a big preventing the ability to do this even if we wanted to. The impact is drop all traffic or permit all in that case. If you were my customer which would you decide? Ask your vendors for these features. Ask them to fix the bugs. The ball rolls uphill here and it's in their lap. Blaming the carriers is wrongheaded and putting it where it doesn't belong in many cases. Happy to discuss offline. - Jared From fergdawgster at mykolab.com Tue Feb 4 18:09:02 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 04 Feb 2014 10:09:02 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> Message-ID: <52F12CBE.6010801@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/4/2014 10:03 AM, Jared Mauch wrote: > Ask your vendors for these features. Ask them to fix the bugs. The > ball rolls uphill here and it's in their lap. Blaming the carriers > is wrongheaded and putting it where it doesn't belong in many > cases. Happy to discuss offline. I'd like to echo Jared's sentiment here -- collectively speaking, service providers need to figure out a way to deal with this issue, before some congresscritters start to try to introduce legislation that will force you to to do it in a way that no one will like. $.02, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLxLL4ACgkQKJasdVTchbJ95AEAm5GcMZUKvy5WDjycH8f4C4Dq 7t1inFCPmGhbmo/456kBAKpUxaf/y7eXVnsxo9/IvULsGEbrf8zdapuAOSUdJrem =v0jF -----END PGP SIGNATURE----- From laszlo at heliacal.net Tue Feb 4 18:45:24 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 4 Feb 2014 18:45:24 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> Message-ID: <8FDC5505-2DEA-4158-8DE6-588423BC96E9@heliacal.net> Why not just provide a public API that lets users specify which of your customers they want to null route? It would save operators the trouble of having to detect the flows.. and you can sell premium access that allows the API user to null route all your other customers at once. Once everyone implements these awesome flow detectors it will just take short bursts of flooding to DoS their customers. If you can detect them in less than a second, it might not even show up on any interface graphs. I think this is already the case at a lot of VPS and hosting providers, since they're such popular sources as well as targets. I don't know what, if anything, is the answer to these problems, but building complex auto-filtering contraptions is not it. Filtering NTP or UDP or any other specific application will just break things more, which is the goal of a 'denial of service' attack. Eventually everything will just be stuffed into TCP port 80 packets and the arms race will continue. The recent abuse of NTP is unfortunate, but it will get fixed. I just wonder if UDP will have to be tunneled inside HTTP by then. Laszlo From Valdis.Kletnieks at vt.edu Tue Feb 4 18:47:46 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Feb 2014 13:47:46 -0500 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: Your message of "Tue, 04 Feb 2014 10:09:02 -0800." <52F12CBE.6010801@mykolab.com> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> <52F12CBE.6010801@mykolab.com> Message-ID: <15487.1391539666@turing-police.cc.vt.edu> On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said: > I'd like to echo Jared's sentiment here -- collectively speaking, > service providers need to figure out a way to deal with this issue, > before some congresscritters start to try to introduce legislation > that will force you to to do it in a way that no one will like. Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? (And yes, I know that in the first case, it urges the customer to cough up the bucks, and in the second case, it's usually not a revenue generator) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bill at herrin.us Tue Feb 4 18:52:04 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 13:52:04 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <8FDC5505-2DEA-4158-8DE6-588423BC96E9@heliacal.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> <8FDC5505-2DEA-4158-8DE6-588423BC96E9@heliacal.net> Message-ID: On Tue, Feb 4, 2014 at 1:45 PM, Laszlo Hanyecz wrote: > Why not just provide a public API that lets users specify which > of your customers they want to null route? They're spoofed packets. There's no way for anyone outside your AS to know which of your customers the packets came from. It's not particularly easy to trace inside your AS either. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From fergdawgster at mykolab.com Tue Feb 4 18:53:51 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 04 Feb 2014 10:53:51 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <15487.1391539666@turing-police.cc.vt.edu> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> <52F12CBE.6010801@mykolab.com> <15487.1391539666@turing-police.cc.vt.edu> Message-ID: <52F1373F.1020206@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/4/2014 10:47 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said: > >> I'd like to echo Jared's sentiment here -- collectively >> speaking, service providers need to figure out a way to deal with >> this issue, before some congresscritters start to try to >> introduce legislation that will force you to to do it in a way >> that no one will like. > > Can somebody explain to me why those who run eyeball networks are > able to block outbound packets when the customer hasn't paid their > bill, but can't seem to block packets that shouldn't be coming from > that cablemodem? > > (And yes, I know that in the first case, it urges the customer to > cough up the bucks, and in the second case, it's usually not a > revenue generator) > It's a dichotomy that is... unexplainable for me personally. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLxNz8ACgkQKJasdVTchbJq6AEApzaaZ9PpPX30kUYAxsGZFzeV WR98y6VBxlocQE2oQFkBANSa4m0/JOGv+PDQovI4xSkjaE/Ru0V8woagAs1hS1C0 =KAL8 -----END PGP SIGNATURE----- From bill at herrin.us Tue Feb 4 18:55:03 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 13:55:03 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> Message-ID: On Tue, Feb 4, 2014 at 1:03 PM, Jared Mauch wrote: >> On Feb 4, 2014, at 11:52 AM, William Herrin wrote: >>> Those that are up in arms about this stuff seem to not be the ones asking >>> the vendors for features and fixes. >> >> Like I said, the "tier 1's" can't be the source of the solution until >> they stop being part of the problem. > > This is the attitude that I've seen elsewhere that is devoid of any meat. > As I said before, we hit a big preventing the ability to do this even if > we wanted to. The impact is drop all traffic or permit all in that case. Hi Jared, I'm not confident you caught the implications of what I said. At the reciprocal peering link, you don't drop the spoofed traffic. You let it flow. You then charge a penalty when it turns out the peering traffic includes spoofed packets. The impact isn't drop or permit. It's dollars. Those who can't or won't control their customer links (where they trivially know what addresses are allowed) start to pay large amounts of money where they peer. More money than it takes to to properly implement customer-link filters so that they don't send spoofed packets to the peer. No new tech. No blocking. Just cashflow. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Tue Feb 4 19:00:16 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Feb 2014 14:00:16 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> <8FDC5505-2DEA-4158-8DE6-588423BC96E9@heliacal.net> Message-ID: On Tue, Feb 4, 2014 at 1:52 PM, William Herrin wrote: > On Tue, Feb 4, 2014 at 1:45 PM, Laszlo Hanyecz wrote: >> Why not just provide a public API that lets users specify which >> of your customers they want to null route? > > They're spoofed packets. There's no way for anyone outside your AS to > know which of your customers the packets came from. It's not > particularly easy to trace inside your AS either. wasn't laszlo joking and sort of making a point about sdn/api/etc usage by customers willy-nilly in your network? (which was sort of my point about customers influencing TE in your network as well) From laszlo at heliacal.net Tue Feb 4 19:01:51 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 4 Feb 2014 19:01:51 +0000 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> <8FDC5505-2DEA-4158-8DE6-588423BC96E9@heliacal.net> Message-ID: <9334B7A6-FE47-4A65-9054-CBE989E70595@heliacal.net> I was joking, I meant that the operator provides an API for attackers, so they can accomplish their goal of taking the customer offline, without having to spoof or flood or whatever else. Automatically installing ACLs in response to observed flows accomplishes almost the same thing. As a concrete example, say a customer is running a game server that utilizes UDP port 12345. An attacker sends a large flow to customer:12345 and your switches and routers all start filtering anything with destination customer:12345, for say 2 hours. Then the attacker can just repeat in 2 hours and send only a few seconds worth of flooding each time. On Feb 4, 2014, at 6:52 PM, William Herrin wrote: > On Tue, Feb 4, 2014 at 1:45 PM, Laszlo Hanyecz wrote: >> Why not just provide a public API that lets users specify which >> of your customers they want to null route? > > They're spoofed packets. There's no way for anyone outside your AS to > know which of your customers the packets came from. It's not > particularly easy to trace inside your AS either. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From bill at herrin.us Tue Feb 4 19:03:57 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 14:03:57 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <9334B7A6-FE47-4A65-9054-CBE989E70595@heliacal.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EF0F3C.1050001@cox.net> <8FDC5505-2DEA-4158-8DE6-588423BC96E9@heliacal.net> <9334B7A6-FE47-4A65-9054-CBE989E70595@heliacal.net> Message-ID: On Tue, Feb 4, 2014 at 2:01 PM, Laszlo Hanyecz wrote: > I was joking, And I was being a tad obtuse. My apoligies. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dougb at dougbarton.us Tue Feb 4 19:08:09 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 04 Feb 2014 11:08:09 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> Message-ID: <52F13A99.10601@dougbarton.us> On 02/04/2014 08:04 AM, William Herrin wrote: > On Sun, Feb 2, 2014 at 5:17 PM, Cb B wrote: >> And, i agree bcp38 would help but that was published 14 years ago. > > Howdy, > > If just three of the transit-free networks rewrote their peering > contracts such that there was a $10k per day penalty for sending > packets with source addresses the peer should reasonably have known > were forged, this problem would go away in a matter of weeks. Granted > it would also be helpful to have a BGP extension signifying > allowed-source-but-don't-route so that RP filtering would work even > when multihomed. Still, even without automatic RP filtering we're > capable of preventing spoofed packets if financially incentivized. > > Thing is, they can't be the source of the solution until they stop > being part of the problem. Won't work because no one will sign that contract. The answer is lawsuits. People who are damaged by DDOS need to file suit against the networks that allowed the spoofed packets. Once it becomes more expensive to allow the spoofing (due to both damages and legal bills) than it is to prevent it, people will work harder to prevent it. Doug From jared at puck.nether.net Tue Feb 4 19:24:17 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 4 Feb 2014 14:24:17 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> Message-ID: <3FB938ED-80A7-47D2-B725-EDD47D895D5A@puck.nether.net> Please let us know your results. Jared Mauch > On Feb 4, 2014, at 1:55 PM, William Herrin wrote: > > On Tue, Feb 4, 2014 at 1:03 PM, Jared Mauch wrote: >>>> On Feb 4, 2014, at 11:52 AM, William Herrin wrote: >>>> Those that are up in arms about this stuff seem to not be the ones asking >>>> the vendors for features and fixes. >>> >>> Like I said, the "tier 1's" can't be the source of the solution until >>> they stop being part of the problem. >> >> This is the attitude that I've seen elsewhere that is devoid of any meat. >> As I said before, we hit a big preventing the ability to do this even if >> we wanted to. The impact is drop all traffic or permit all in that case. > > Hi Jared, > > I'm not confident you caught the implications of what I said. At the > reciprocal peering link, you don't drop the spoofed traffic. You let > it flow. You then charge a penalty when it turns out the peering > traffic includes spoofed packets. The impact isn't drop or permit. > It's dollars. Those who can't or won't control their customer links > (where they trivially know what addresses are allowed) start to pay > large amounts of money where they peer. More money than it takes to to > properly implement customer-link filters so that they don't send > spoofed packets to the peer. > > No new tech. No blocking. Just cashflow. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From jra at baylink.com Tue Feb 4 19:28:23 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Feb 2014 14:28:23 -0500 (EST) Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> Message-ID: <21114487.7238.1391542102964.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > Ask your vendors for these features. Ask them to fix the bugs. The > ball rolls uphill here and it's in their lap. Blaming the carriers is > wrongheaded and putting it where it doesn't belong in many cases. > Happy to discuss offline. I phrased that a bit more stridently here: http://www.bcp38.info/index.php/Information_for_equipment_manufacturers Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bill at herrin.us Tue Feb 4 19:28:22 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 14:28:22 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52F13A99.10601@dougbarton.us> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52F13A99.10601@dougbarton.us> Message-ID: On Tue, Feb 4, 2014 at 2:08 PM, Doug Barton wrote: > On 02/04/2014 08:04 AM, William Herrin wrote: >> If just three of the transit-free networks rewrote their peering >> contracts such that there was a $10k per day penalty for sending >> packets with source addresses the peer should reasonably have known >> were forged, this problem would go away in a matter of weeks. > > Won't work because no one will sign that contract. Hi Doug, Verizon Business is willing to do settlement-free peering with you but you won't agree to a reciprocal penalty if either allows its customers to forge packets? I call that a weed-out factor. Weed out the bad actors because anyone else would consider that peering arrangement too valuable to pass up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Tue Feb 4 19:33:10 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Feb 2014 14:33:10 -0500 (EST) Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <15487.1391539666@turing-police.cc.vt.edu> Message-ID: <13482218.7240.1391542390542.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > Can somebody explain to me why those who run eyeball networks are able > to block outbound packets when the customer hasn't paid their bill, > but can't seem to block packets that shouldn't be coming from that > cablemodem? The purported argument is "our edge concentrators don't have that knob/ enough horsepower to do it manually and stay on the line card". I'm not sure how accurate that argument is any more and (as I noted in another reply just now[1]), I'm officially not buying it anymore. Cheers, -- jra [1] http://www.bcp38.info/index.php/Information_for_equipment_manufacturers -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Tue Feb 4 19:35:33 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Feb 2014 14:35:33 -0500 (EST) Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <52F1373F.1020206@mykolab.com> Message-ID: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Ferguson" > > (And yes, I know that in the first case, it urges the customer to > > cough up the bucks, and in the second case, it's usually not a > > revenue generator) > > It's a dichotomy that is... unexplainable for me personally. Nope: it's easy to explain; you merely have to be a cynical bastard: Attack traffic takes up bandwidth. Providers sell bandwidth. It *is in their commercial best interest (read: maximizing shareholder value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is forced -- it's actually their fiduciary duty not to. *THIS* is the problem we have to fix. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From morrowc.lists at gmail.com Tue Feb 4 19:38:50 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Feb 2014 14:38:50 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52F13A99.10601@dougbarton.us> Message-ID: On Tue, Feb 4, 2014 at 2:28 PM, William Herrin wrote: > On Tue, Feb 4, 2014 at 2:08 PM, Doug Barton wrote: >> On 02/04/2014 08:04 AM, William Herrin wrote: >>> If just three of the transit-free networks rewrote their peering >>> contracts such that there was a $10k per day penalty for sending >>> packets with source addresses the peer should reasonably have known >>> were forged, this problem would go away in a matter of weeks. >> >> Won't work because no one will sign that contract. > > Hi Doug, > > Verizon Business is willing to do settlement-free peering with you but you forgot an IF there, right? All of these 'get N tierM networks to peer and agree to penalties amongst eachother in the case of Y happening' discussions sound a LOT like longdistance settlement regimes. There's a nice fellow in tcpm/iccrwg in the ietf that's happy to talk a lot about 'red packets' and 'black packets' and congestion and cost shifting for this sort of thing. which frankly sounds almost exactly like the conversation about spoofed packets. In a world where folk connect to a peering fabric and default-route toward a peer, or never send routes to a peer yet prefer paths across that peer... or hell, do this with their ISP network connections. How does one tell that 'ISPX sent me a packet that is spoofed' ? how does that hold up in court? (which will happen eventually when the billing dispute goes south... and will happen months after the event in question.) It's a laudable goal, to do some enforcement of bcp38-like functions, but doing at SFP links is frankly impactical and bound to fail. Instead, concentrate on the customer edge of the problem and solve things there, eh? -chris From msa at latt.net Tue Feb 4 19:48:40 2014 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 4 Feb 2014 14:48:40 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52F13A99.10601@dougbarton.us> Message-ID: <20140204194839.GC22916@puck.nether.net> On Tue, Feb 04, 2014 at 02:28:22PM -0500, William Herrin wrote: > Verizon Business is willing to do settlement-free peering with you but > you won't agree to a reciprocal penalty if either allows its customers > to forge packets? I call that a weed-out factor. Weed out the bad > actors because anyone else would consider that peering arrangement too > valuable to pass up. Bill, Are you willing to warrant the source, destination and lawful purpose of every single frame exiting your network? (Insert usual encouraging of competition to do same, etc., etc.) --msa From damian at google.com Tue Feb 4 19:54:52 2014 From: damian at google.com (Damian Menscher) Date: Tue, 4 Feb 2014 11:54:52 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <52F13A99.10601@dougbarton.us> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52F13A99.10601@dougbarton.us> Message-ID: On Tue, Feb 4, 2014 at 11:08 AM, Doug Barton wrote: > The answer is lawsuits. People who are damaged by DDOS need to file suit > against the networks that allowed the spoofed packets. Once it becomes more > expensive to allow the spoofing (due to both damages and legal bills) than > it is to prevent it, people will work harder to prevent it. +1 for this. While lawsuits rarely improve a situation, I agree it's probably the only way to shift costs back to the bad networks. But then the problem shifts to one of detection and tracing. The bad networks can only be identified if the transit providers have netflow. When I ask transit providers to trace spoofed packets they either don't respond or claim their netflow was temporarily broken. It's not just transit providers, though -- many spoofed attacks come through IXPs. To help, the IXPs need to provide sflow that shows which peers traffic is coming from. I've seen some basic functionality at AMS-IX for this, but unfortunately it's just rrd graphs, not full data. Still, they're better than most. And then the IXPs need to have a policy forbidding spoofed packets. Damian From bill at herrin.us Tue Feb 4 20:01:09 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 15:01:09 -0500 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: <20140204194839.GC22916@puck.nether.net> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52F13A99.10601@dougbarton.us> <20140204194839.GC22916@puck.nether.net> Message-ID: On Tue, Feb 4, 2014 at 2:48 PM, Majdi S. Abbas wrote: > Are you willing to warrant the source, destination and lawful > purpose of every single frame exiting your network? Yes, no and no respectively. As a BGP leaf node, I can guarantee that no packets leave my network from a source address that isn't mine. The destination I can't control -- my software will respond to any apparently legitimate external query. As for legal, even if I'm fortunate enough to never have a customer hijacked into a botnet, there are a vast number of legal systems in the world and no practical way to be sure that a given communication is legitimate in all of them. But by golly I have total control over the source address in packets leaving my network. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From goemon at anime.net Tue Feb 4 20:21:49 2014 From: goemon at anime.net (goemon at anime.net) Date: Tue, 4 Feb 2014 12:21:49 -0800 (PST) Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <15487.1391539666@turing-police.cc.vt.edu> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> <52F12CBE.6010801@mykolab.com> <15487.1391539666@turing-police.cc.vt.edu> Message-ID: On Tue, 4 Feb 2014, Valdis.Kletnieks at vt.edu wrote: > On Tue, 04 Feb 2014 10:09:02 -0800, Paul Ferguson said: > >> I'd like to echo Jared's sentiment here -- collectively speaking, >> service providers need to figure out a way to deal with this issue, >> before some congresscritters start to try to introduce legislation >> that will force you to to do it in a way that no one will like. > > Can somebody explain to me why those who run eyeball networks are able > to block outbound packets when the customer hasn't paid their bill, > but can't seem to block packets that shouldn't be coming from that > cablemodem? > > (And yes, I know that in the first case, it urges the customer to cough > up the bucks, and in the second case, it's usually not a revenue generator) > The only way this is going to get fixed is to make it more expensive to originate abuse than it is to block it. The only thing management is going to pay attention to is their pocketbooks. -Dan From jim.rampley at charter.com Tue Feb 4 20:34:55 2014 From: jim.rampley at charter.com (Rampley Jr, Jim F) Date: Tue, 4 Feb 2014 14:34:55 -0600 Subject: Visual tools for RSVP-TE Message-ID: I'm curious what tools different organizations are using to provision, manage, and visually see how constraint based LSP's are routed over your network. Jim From alvarezp at alvarezp.ods.org Tue Feb 4 20:55:38 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 04 Feb 2014 12:55:38 -0800 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> Message-ID: <52F153CA.20708@alvarezp.ods.org> On 04/02/14 11:35, Jay Ashworth wrote: > It *is in their commercial best interest (read: maximizing shareholder > value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is > forced -- it's actually their fiduciary duty not to. That's short-sighted, but I agree in that that's what happens. Not filtering doesn't prevent them to operate. > *THIS* is the problem we have to fix. Source-based routing when going back to the backbone, at least on IPv6. It allows end-user multihoming with no BGP, and routers could be programmed to, by default, drop packages that don't know how to source-route, hence, automatically source filtering for those that don't care enough. Difficult to do. Will take years to develop and adopt... if at all. From hannigan at gmail.com Tue Feb 4 21:56:44 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 4 Feb 2014 16:56:44 -0500 Subject: NANOG 60 ATL Data Center Track Update Message-ID: All, We are planning to experiment with a change in the way "personals", a long standing tradition in the Peering Track, are done and in the Data Center track at NANOG 60 in Atlanta. The track is being held Monday starting at 4:45 and running through 6:15. Instead of data center operators presenting, the hosts or a member of the data center community will present a brief summary of regional data center bullet points. If you operate a data center in Georgia, North Carolina, South Carolina and Alabama, respond with the following bullet point answers by Friday. If we can't fit everyone, apologies in advance. 1. mW committed from utility? 2. mW currently available? 3. Any Facility Certifications? 4. Gross Square Footage of Data Center? 5. Net Square Footage available in Data Center? 6. Design PUE? 7. Wholesale, Retail Colo or Both? 8. Date Active? 9. Number of dual routed providers operational? Along with this, we'll be presenting short summaries related to recent, interesting, developments in the industry related to space, power and people. See the track agenda at http://bit.ly/1jbZ9aY Best Regards, -M< From marka at isc.org Tue Feb 4 22:00:39 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Feb 2014 09:00:39 +1100 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: Your message of "Tue, 04 Feb 2014 14:35:33 -0500." <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> Message-ID: <20140204220039.A77B0E52DCC@rock.dv.isc.org> In message <977303.7242.1391542533531.JavaMail.root at benjamin.baylink.com>, Jay Ashworth writes: > ----- Original Message ----- > > From: "Paul Ferguson" > > > > (And yes, I know that in the first case, it urges the customer to > > > cough up the bucks, and in the second case, it's usually not a > > > revenue generator) > > > > It's a dichotomy that is... unexplainable for me personally. > > Nope: it's easy to explain; you merely have to be a cynical bastard: > > Attack traffic takes up bandwidth. > > Providers sell bandwidth. > > It *is in their commercial best interest (read: maximizing shareholder > value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is > forced -- it's actually their fiduciary duty not to. Then the need to be made criminally liable for the damage that it causes. Yes, the directors of these companies need to serve gaol time. > *THIS* is the problem we have to fix. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DI > I > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ttauber at 1-4-5.net Tue Feb 4 22:14:40 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 4 Feb 2014 17:14:40 -0500 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <15487.1391539666@turing-police.cc.vt.edu> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> <52F12CBE.6010801@mykolab.com> <15487.1391539666@turing-police.cc.vt.edu> Message-ID: On Tue, Feb 4, 2014 at 1:47 PM, wrote: > > Can somebody explain to me why those who run eyeball networks are able > to block outbound packets when the customer hasn't paid their bill, > but can't seem to block packets that shouldn't be coming from that > cablemodem? > The DOCSIS spec has source address verification (as I understand it, for about a decade.) It is deployed within at least one large cable access provider network I am familiar with (though I don't personally work on the DOCSIS side of things). Why don't enterprises, hosting and cloud providers do it? (I don't know that they don't, but I figured I'd just keep with the tone.) Enterprises know what prefixes they have so should drop outbound packets with source IPs other than those, right? Likewise hosting providers ought to put in some safeguards. What about cloud providers who also provide virtual OSes and other software? Are those VMs and their third-party software kept patched? All those folks also provide access at the network edge. Tony From johnl at iecc.com Tue Feb 4 22:18:21 2014 From: johnl at iecc.com (John Levine) Date: 4 Feb 2014 22:18:21 -0000 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: Message-ID: <20140204221821.57348.qmail@joyce.lan> >>> If just three of the transit-free networks rewrote their peering >>> contracts such that there was a $10k per day penalty for sending >>> packets with source addresses the peer should reasonably have known >>> were forged, this problem would go away in a matter of weeks. >> >> Won't work because no one will sign that contract. Oh, right, how hard can it be to put a bell on that pesky cat? I was at a conference with people from some Very Large ISPs. They told me that many of their large customers absolutely will not let them do BCP38 filtering. ("If you don't want our business, we can find someone else who does.") The usual problem is that they have PA space from two providers and for various reasons, not all of which are stupid, traffic with provider A's addresses sometimes goes out through provider B. Adding to the excitement, some of these customers are medium sized ISPs with multihomed customers of their own. I don't know BGP well enough to know if it's possible to send out announcements for this situtation, this address range is us, but don't route traffic to it. Even if it is, not all of the customers do BGP, some are just stub networks. If we could figure out a reasonable way (i.e., one that the customers might be willing to implement) to handle this, it'll make BCP38 a lot more doable. R's, John From fergdawgster at mykolab.com Tue Feb 4 22:27:55 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 04 Feb 2014 14:27:55 -0800 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140204221821.57348.qmail@joyce.lan> References: <20140204221821.57348.qmail@joyce.lan> Message-ID: <52F1696B.5090401@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/4/2014 2:18 PM, John Levine wrote: >>>> If just three of the transit-free networks rewrote their >>>> peering contracts such that there was a $10k per day penalty >>>> for sending packets with source addresses the peer should >>>> reasonably have known were forged, this problem would go away >>>> in a matter of weeks. >>> >>> Won't work because no one will sign that contract. > > Oh, right, how hard can it be to put a bell on that pesky cat? > > > I was at a conference with people from some Very Large ISPs. They > told me that many of their large customers absolutely will not let > them do BCP38 filtering. ("If you don't want our business, we can > find someone else who does.") The usual problem is that they have > PA space from two providers and for various reasons, not all of > which are stupid, traffic with provider A's addresses sometimes > goes out through provider B. Adding to the excitement, some of > these customers are medium sized ISPs with multihomed customers of > their own. > > I don't know BGP well enough to know if it's possible to send out > announcements for this situtation, this address range is us, but > don't route traffic to it. Even if it is, not all of the customers > do BGP, some are just stub networks. > > If we could figure out a reasonable way (i.e., one that the > customers might be willing to implement) to handle this, it'll make > BCP38 a lot more doable. > BCP84? :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLxaWoACgkQKJasdVTchbIy9AD/eILZC1RBKpcnSGfYvmWhkmiF L1egq0XmR2EqlG9ta5ABALrHWUwaV0COd5I6Mz6vZL2Zoa2AkO1w7DC6hvcGAIkM =R7VB -----END PGP SIGNATURE----- From cra at WPI.EDU Tue Feb 4 22:36:18 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 4 Feb 2014 17:36:18 -0500 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140204221821.57348.qmail@joyce.lan> References: <20140204221821.57348.qmail@joyce.lan> Message-ID: <20140204223616.GF11142@angus.ind.WPI.EDU> On Tue, Feb 04, 2014 at 10:18:21PM -0000, John Levine wrote: > I was at a conference with people from some Very Large ISPs. They > told me that many of their large customers absolutely will not let > them do BCP38 filtering. ("If you don't want our business, we can > find someone else who does.") The usual problem is that they have PA > space from two providers and for various reasons, not all of which are > stupid, traffic with provider A's addresses sometimes goes out through > provider B. Adding to the excitement, some of these customers are > medium sized ISPs with multihomed customers of their own. > > I don't know BGP well enough to know if it's possible to send out > announcements for this situtation, this address range is us, but don't > route traffic to it. Even if it is, not all of the customers do BGP, > some are just stub networks. > > If we could figure out a reasonable way (i.e., one that the customers > might be willing to implement) to handle this, it'll make BCP38 a lot > more doable. No-Advertise or No-Export community? From bill at herrin.us Tue Feb 4 22:49:18 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 17:49:18 -0500 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140204221821.57348.qmail@joyce.lan> References: <20140204221821.57348.qmail@joyce.lan> Message-ID: On Tue, Feb 4, 2014 at 5:18 PM, John Levine wrote: > I was at a conference with people from some Very Large ISPs. They > told me that many of their large customers absolutely will not let > them do BCP38 filtering. ("If you don't want our business, we can > find someone else who does.") The usual problem is that they have PA > space from two providers and for various reasons, not all of which are > stupid, traffic with provider A's addresses sometimes goes out through > provider B. Then: (A) It isn't spoofed traffic. The relevant block of ISP A's addresses should be permitted in ISP B's filter. It shouldn't even need much in the way of verification: confirm that the requested block is either relatively small and not obviously registered to someone else in rwhois, or confirm that it is registered to the customer in rwhois. (B) When it comes time to apply a penalty up at the peering sessions, those packets aren't eligible. The penalty can be refuted and, if based on those particular source addresses, dropped. > I don't know BGP well enough to know if it's possible to send out > announcements for this situtation, this address range is us, but don't > route traffic to it. No. A BGP option could be added to support this, but in many cases the blocks in question are smaller than /24. The advertisements would end up filtered anyway. There really isn't a good technical solution to automated filtering at the reciprocal peering level. That part only works at the customer edge. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From surfer at mauigateway.com Tue Feb 4 22:52:37 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 4 Feb 2014 14:52:37 -0800 Subject: TWC (AS11351) blocking all NTP? Message-ID: <20140204145237.DC21AEFF@m0005298.ppops.net> ----------------------------- > We block all outbound UDP for our ~200,000 Users for this very reason > (with the exception of some whitelisted NTP and DNS servers). So far > we have had 0 complaints ----------------------------- Because those that might complain switched providers when their internet broke instead of complaining and hoping something might change? scott From alvarezp at alvarezp.ods.org Tue Feb 4 23:00:18 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 04 Feb 2014 15:00:18 -0800 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140204221821.57348.qmail@joyce.lan> References: <20140204221821.57348.qmail@joyce.lan> Message-ID: <52F17102.2000505@alvarezp.ods.org> On 04/02/14 14:18, John Levine wrote: > I was at a conference with people from some Very Large ISPs. They > told me that many of their large customers absolutely will not let > them do BCP38 filtering. ("If you don't want our business, we can > find someone else who does.") The usual problem is that they have PA > space from two providers and for various reasons, not all of which > are stupid, traffic with provider A's addresses sometimes goes out > through provider B. Adding to the excitement, some of these > customers are medium sized ISPs with multihomed customers of their > own. I haven't read it all, but section 3 says: > However, by restricting transit traffic which originates from a > downstream network to known, and intentionally advertised, > prefix(es), the problem of source address spoofing can be virtually > eliminated in this attack scenario. If ISP has customer A with multiple *known* valid networks --doesn't matter if ISP allocated them to customer or not-- and ISP lets them all out, but filters everything else, ISP is still complying with BCP 38. Here it's not a matter of blocking "just because". It's blocking unknown addresses. It doesn't either mean that ISP should not open the filters if a new prefix is requested by the customer. From owen at delong.com Tue Feb 4 23:06:55 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Feb 2014 15:06:55 -0800 Subject: NANOG 60 ATL Data Center Track Update In-Reply-To: References: Message-ID: <4F34B08D-246D-4B91-8800-39E9CF9CFAB9@delong.com> Do you really mean ?And?? in which case I expect the list would be _VERY_ short, or do you mean ?and/or?? Owen On Feb 4, 2014, at 1:56 PM, Martin Hannigan wrote: > All, > > We are planning to experiment with a change in the way "personals", a long > standing tradition in the Peering Track, are done and in the Data Center > track at NANOG 60 in Atlanta. The track is being held Monday starting at > 4:45 and running through 6:15. Instead of data center operators presenting, > the hosts or a member of the data center community will present a brief > summary of regional data center bullet points. > > If you operate a data center in Georgia, North Carolina, South Carolina and > Alabama, respond with the following bullet point answers by Friday. If we > can't fit everyone, apologies in advance. > > 1. mW committed from utility? > 2. mW currently available? > 3. Any Facility Certifications? > 4. Gross Square Footage of Data Center? > 5. Net Square Footage available in Data Center? > 6. Design PUE? > 7. Wholesale, Retail Colo or Both? > 8. Date Active? > 9. Number of dual routed providers operational? > > Along with this, we'll be presenting short summaries related to recent, > interesting, developments in the industry related to space, power and > people. > > See the track agenda at http://bit.ly/1jbZ9aY > > > Best Regards, > > -M< From randy at psg.com Tue Feb 4 23:08:11 2014 From: randy at psg.com (Randy Bush) Date: Wed, 05 Feb 2014 08:08:11 +0900 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <15487.1391539666@turing-police.cc.vt.edu> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> <72280728-A8B6-4382-9F29-32082EE88042@puck.nether.net> <52F12CBE.6010801@mykolab.com> <15487.1391539666@turing-police.cc.vt.edu> Message-ID: > Can somebody explain to me why those who run eyeball networks are able > to block outbound packets when the customer hasn't paid their bill, > but can't seem to block packets that shouldn't be coming from that > cablemodem? i suspect the non-payment case is solved at a layer below three randy From randy at psg.com Tue Feb 4 23:13:06 2014 From: randy at psg.com (Randy Bush) Date: Wed, 05 Feb 2014 08:13:06 +0900 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140204220039.A77B0E52DCC@rock.dv.isc.org> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> Message-ID: > Then the need to be made criminally liable for the damage that it causes. > Yes, the directors of these companies need to serve gaol time. why not just have god send down lightning bolts? quicker and cheaper. or maybe they will just drown as the level of hyperbole keeps rising. randy From johnl at iecc.com Tue Feb 4 23:24:22 2014 From: johnl at iecc.com (John R. Levine) Date: 4 Feb 2014 18:24:22 -0500 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <52F17102.2000505@alvarezp.ods.org> References: <20140204221821.57348.qmail@joyce.lan> <52F17102.2000505@alvarezp.ods.org> Message-ID: > If ISP has customer A with multiple *known* valid networks --doesn't matter > if ISP allocated them to customer or not-- and ISP lets them all out, but > filters everything else, ISP is still complying with BCP 38. Of course. The question is how the ISP knows what the customer's address ranges are, without demanding vast amounts of nitpicky manual work on both sides. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From alter3d at alter3d.ca Tue Feb 4 23:35:13 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 04 Feb 2014 18:35:13 -0500 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140204220039.A77B0E52DCC@rock.dv.isc.org> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> Message-ID: <52F17931.40604@alter3d.ca> On 2/4/2014 5:00 PM, Mark Andrews wrote: >> Nope: it's easy to explain; you merely have to be a cynical bastard: >> >> Attack traffic takes up bandwidth. >> >> Providers sell bandwidth. >> >> It *is in their commercial best interest (read: maximizing shareholder >> value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is >> forced -- it's actually their fiduciary duty not to. > Then the need to be made criminally liable for the damage that it causes. > Yes, the directors of these companies need to serve gaol time. That would never fly, because it would put the politicians at odds with the telecom buddies that make huge political donations. Hard to throw someone in jail then hit them up for campaign money. What will probably happen is the same thing we do with everything else that might be used for evil purposes but where we don't want to tackle the real underlying problem -- just write a law banning something and hope the problem goes away. Make it illegal to posses a device capable of bandwith greater than 33.6Kbps without a special license, and BAM -- no more problems, overnight. For added political-style points, tack on a catchy moniker, like "Immoral Bandwidth Prohibition", "The War on DDOS", or "High-Capacity Digital Assault Bandwidth" to help sell it to the public. The public will be OK with their funny cat videos taking 19 hours to load if they know they're preventing bad guys from doing something evil. After all, it's worked flawlessly for alcohol, drugs and guns, so it MUST work for networks... and it's much easier than those silly, so-called "solutions" y'all are talking about! :p - Pete (P.S. Dear politicians: in case you're reading this, the above was satire and should not be construed as anything resembling a good idea.) From robertg at garlic.com Tue Feb 4 23:44:14 2014 From: robertg at garlic.com (Robert Glover) Date: Tue, 04 Feb 2014 15:44:14 -0800 Subject: Cogent <-> Verizon peering congestion Message-ID: <52F17B4E.20808@garlic.com> Hello, For the last several months, we have been tracking a congestion issue between Cogent <-> Verizon Host Loss% Snt Last Avg Best Wrst StDev 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 161.1 29.5 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 2.4 3.6 0.2 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 4.8 0.2 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 5.5 0.3 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 6.9 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 171.6 271.6 24.8 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 171.7 250.8 18.3 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 195.5 199.2 0.8 We have smokeping's from our side showing 30%+ packet loss from us (AS4307) to Verizon. All I have gotten from Cogent is a canned response: --- The latency and/or packet loss that you are experiencing to this destination is due to occasional high traffic with Verizon. We have repeatedly requested augments to these congestion points and hope Verizon will comply soon. While this has been escalated internally to the CEO level, we encourage you to also contact Verizon customer support with your concerns and complaints. Their delay is a major impediment to internet traffic overall and contrary to net neutrality requirements. Our peering engineers will continue to address this on a daily basis until resolved. --- It seems to have gotten a lot worse in recent days, to the point where we have customers who are trying to access us from Verizon's network (i.e. they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having a very hard to checking their email, etc. Has anyone else been experiencing these issues? Or does anyone have more information that what Cogent provided me in their canned statement? -Bobby From marka at isc.org Tue Feb 4 23:46:47 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Feb 2014 10:46:47 +1100 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "Tue, 04 Feb 2014 15:00:18 -0800." <52F17102.2000505@alvarezp.ods.org> References: <20140204221821.57348.qmail@joyce.lan> <52F17102.2000505@alvarezp.ods.org> Message-ID: <20140204234647.97024E537F6@rock.dv.isc.org> In message <52F17102.2000505 at alvarezp.ods.org>, Octavio Alvarez writes: > On 04/02/14 14:18, John Levine wrote: > > I was at a conference with people from some Very Large ISPs. They > > told me that many of their large customers absolutely will not let > > them do BCP38 filtering. ("If you don't want our business, we can > > find someone else who does.") The usual problem is that they have PA > > space from two providers and for various reasons, not all of which > > are stupid, traffic with provider A's addresses sometimes goes out > > through provider B. Adding to the excitement, some of these > > customers are medium sized ISPs with multihomed customers of their > > own. > > I haven't read it all, but section 3 says: > > > However, by restricting transit traffic which originates from a > > downstream network to known, and intentionally advertised, > > prefix(es), the problem of source address spoofing can be virtually > > eliminated in this attack scenario. > > If ISP has customer A with multiple *known* valid networks --doesn't > matter if ISP allocated them to customer or not-- and ISP lets them all > out, but filters everything else, ISP is still complying with BCP 38. > > Here it's not a matter of blocking "just because". It's blocking unknown > addresses. It doesn't either mean that ISP should not open the filters > if a new prefix is requested by the customer. Or downstream customers. SIDR provides provides the crypotographic glue that can be used to automate this. The end customer has a CERT which authenticates their use of the address. The second ISP supplies a CERT which the end customer signs saying they can source this range. Repeat until you reach a big enough ISP that you just have a agreement that no unverified traffic will injected down the link. These CERTS can then be used to build perfect input and output filters. Initially you may have to have manual inputs but with increasing use of SIDR the amount of manual intervention will drop. I.e. If you multi-home you need to have provable use of the address space. This isn't significantly different to the regular use of SIDR. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Wed Feb 5 00:18:56 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Feb 2014 19:18:56 -0500 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140204221821.57348.qmail@joyce.lan> <52F17102.2000505@alvarezp.ods.org> Message-ID: On Tue, Feb 4, 2014 at 6:24 PM, John R. Levine wrote: >> If ISP has customer A with multiple *known* valid networks --doesn't >> matter if ISP allocated them to customer or not-- and ISP lets them all out, >> but filters everything else, ISP is still complying with BCP 38. > > Of course. The question is how the ISP knows what the customer's address > ranges are, without demanding vast amounts of nitpicky manual work on both > sides. Hi John, "whois 1.2.3.4" Why does it have to be hard? Restricting the filter to addresses which (A) the customer asserts are theirs and (B) aren't obviously registered to someone else would more than solve the problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alvarezp at alvarezp.ods.org Wed Feb 5 00:23:01 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 04 Feb 2014 16:23:01 -0800 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140204221821.57348.qmail@joyce.lan> <52F17102.2000505@alvarezp.ods.org> Message-ID: <52F18465.2080003@alvarezp.ods.org> On 04/02/14 15:24, John R. Levine wrote: >> If ISP has customer A with multiple *known* valid networks --doesn't >> matter if ISP allocated them to customer or not-- and ISP lets them >> all out, but filters everything else, ISP is still complying with BCP 38. > > Of course. The question is how the ISP knows what the customer's > address ranges are, without demanding vast amounts of nitpicky manual > work on both sides. The same way BGP outbound prefix filters are applied nowadays, would be a good start. Some have BGP filtering but don't have ACLs. From johnl at iecc.com Wed Feb 5 00:29:05 2014 From: johnl at iecc.com (John Levine) Date: 5 Feb 2014 00:29:05 -0000 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: Message-ID: <20140205002905.57856.qmail@joyce.lan> >Why does it have to be hard? Restricting the filter to addresses which >(A) the customer asserts are theirs How does the customer do that in a way that scales? I don't think any of this is rocket science, but it apparently is a real block to BCP38/84 implementatin. R's, John From edwardroels at gmail.com Wed Feb 5 00:29:56 2014 From: edwardroels at gmail.com (Edward Roels) Date: Tue, 4 Feb 2014 19:29:56 -0500 Subject: Cogent <-> Verizon peering congestion In-Reply-To: <52F17B4E.20808@garlic.com> References: <52F17B4E.20808@garlic.com> Message-ID: I also see major congestion from Cogent to VZ. Amongst other major networks. http://i.imgur.com/1z2ZGOr.png On Tue, Feb 4, 2014 at 6:44 PM, Robert Glover wrote: > Hello, > > For the last several months, we have been tracking a congestion issue > between Cogent <-> Verizon > > Host Loss% Snt Last Avg Best Wrst StDev > 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 > 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 > 161.1 29.5 > 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 > 2.4 3.6 0.2 > 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 > 4.8 0.2 > 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 > 5.5 0.3 > 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 > 6.9 > 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 > 171.6 271.6 24.8 > 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 > 171.7 250.8 18.3 > 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 > 195.5 199.2 0.8 > > We have smokeping's from our side showing 30%+ packet loss from us > (AS4307) to Verizon. > > All I have gotten from Cogent is a canned response: > > --- > The latency and/or packet loss that you are experiencing to this > destination is due to occasional high traffic with Verizon. We have > repeatedly requested augments to these congestion points and hope Verizon > will comply soon. While this has been escalated internally to the CEO > level, we encourage you to also contact Verizon customer support with your > concerns and complaints. Their delay is a major impediment to internet > traffic overall and contrary to net neutrality requirements. Our peering > engineers will continue to address this on a daily basis until resolved. > --- > > It seems to have gotten a lot worse in recent days, to the point where we > have customers who are trying to access us from Verizon's network (i.e. > they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having > a very hard to checking their email, etc. > > Has anyone else been experiencing these issues? Or does anyone have more > information that what Cogent provided me in their canned statement? > > -Bobby > > From Jason_Livingood at cable.comcast.com Wed Feb 5 00:31:58 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 5 Feb 2014 00:31:58 +0000 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: Message-ID: >>Can somebody explain to me why those who run eyeball networks are able >> to block outbound packets when the customer hasn't paid their bill, >> but can't seem to block packets that shouldn't be coming from that >> cablemodem? > >i suspect the non-payment case is solved at a layer below three In a DOCSIS network the source address verification (as Tony said) is typically done on the CMTS IIRC. Turning a customer off for non-payment is done in an accounts management / billing system. While I am sure continuing to agree with each other that spoofing is bad, we lack actionable data. ;-) As I said in another thread, I think someone / some group needs to invest to collect actual data and share the results openly. So any volunteers out there? I?m sure there are lots of ways to underwrite independent research on the subject (contact me off-list). Jason From aaron at wholesaleinternet.net Wed Feb 5 00:40:09 2014 From: aaron at wholesaleinternet.net (Aaron) Date: Tue, 04 Feb 2014 18:40:09 -0600 Subject: Cogent <-> Verizon peering congestion In-Reply-To: References: <52F17B4E.20808@garlic.com> Message-ID: <52F18869.60808@wholesaleinternet.net> I've seen some Cogent-Sprint congestion today also. About 10% PL at the link. On 2/4/2014 6:29 PM, Edward Roels wrote: > I also see major congestion from Cogent to VZ. Amongst other major > networks. > > > http://i.imgur.com/1z2ZGOr.png > > > > On Tue, Feb 4, 2014 at 6:44 PM, Robert Glover wrote: > >> Hello, >> >> For the last several months, we have been tracking a congestion issue >> between Cogent <-> Verizon >> >> Host Loss% Snt Last Avg Best Wrst StDev >> 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 >> 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 >> 161.1 29.5 >> 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 >> 2.4 3.6 0.2 >> 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 >> 4.8 0.2 >> 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 >> 5.5 0.3 >> 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 >> 6.9 >> 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 >> 171.6 271.6 24.8 >> 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 >> 171.7 250.8 18.3 >> 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 >> 195.5 199.2 0.8 >> >> We have smokeping's from our side showing 30%+ packet loss from us >> (AS4307) to Verizon. >> >> All I have gotten from Cogent is a canned response: >> >> --- >> The latency and/or packet loss that you are experiencing to this >> destination is due to occasional high traffic with Verizon. We have >> repeatedly requested augments to these congestion points and hope Verizon >> will comply soon. While this has been escalated internally to the CEO >> level, we encourage you to also contact Verizon customer support with your >> concerns and complaints. Their delay is a major impediment to internet >> traffic overall and contrary to net neutrality requirements. Our peering >> engineers will continue to address this on a daily basis until resolved. >> --- >> >> It seems to have gotten a lot worse in recent days, to the point where we >> have customers who are trying to access us from Verizon's network (i.e. >> they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having >> a very hard to checking their email, etc. >> >> Has anyone else been experiencing these issues? Or does anyone have more >> information that what Cogent provided me in their canned statement? >> >> -Bobby >> >> From jamesl at mythostech.com Wed Feb 5 00:47:48 2014 From: jamesl at mythostech.com (James Laszko) Date: Wed, 5 Feb 2014 00:47:48 +0000 Subject: Cogent <-> Verizon peering congestion In-Reply-To: <52F17B4E.20808@garlic.com> References: <52F17B4E.20808@garlic.com> Message-ID: <706B4A52-819F-44C7-9688-199150206669@mythostech.com> Yep. Major oversub in our area (LA/SD) - worse for us is same with VZ <-> L3! James Laszko Mythos Technology Inc jamesl at mythostech.com Sent from my iPhone > On Feb 4, 2014, at 3:46 PM, "Robert Glover" wrote: > > Hello, > > For the last several months, we have been tracking a congestion issue between Cogent <-> Verizon > > Host Loss% Snt Last Avg Best Wrst StDev > 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 > 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 161.1 29.5 > 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 2.4 3.6 0.2 > 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 4.8 0.2 > 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 5.5 0.3 > 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 6.9 > 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 171.6 271.6 24.8 > 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 171.7 250.8 18.3 > 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 195.5 199.2 0.8 > > We have smokeping's from our side showing 30%+ packet loss from us (AS4307) to Verizon. > > All I have gotten from Cogent is a canned response: > > --- > The latency and/or packet loss that you are experiencing to this destination is due to occasional high traffic with Verizon. We have repeatedly requested augments to these congestion points and hope Verizon will comply soon. While this has been escalated internally to the CEO level, we encourage you to also contact Verizon customer support with your concerns and complaints. Their delay is a major impediment to internet traffic overall and contrary to net neutrality requirements. Our peering engineers will continue to address this on a daily basis until resolved. > --- > > It seems to have gotten a lot worse in recent days, to the point where we have customers who are trying to access us from Verizon's network (i.e. they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having a very hard to checking their email, etc. > > Has anyone else been experiencing these issues? Or does anyone have more information that what Cogent provided me in their canned statement? > > -Bobby > From marka at isc.org Wed Feb 5 00:48:06 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Feb 2014 11:48:06 +1100 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: Your message of "05 Feb 2014 00:29:05 -0000." <20140205002905.57856.qmail@joyce.lan> References: <20140205002905.57856.qmail@joyce.lan> Message-ID: <20140205004806.C3F97E542B1@rock.dv.isc.org> In message <20140205002905.57856.qmail at joyce.lan>, "John Levine" writes: > >Why does it have to be hard? Restricting the filter to addresses which > >(A) the customer asserts are theirs > > How does the customer do that in a way that scales? You implement SIDR to the extent where you issue your multi homed customers CERTs for the address space you allocated to them. The customer can then just send signed requests to a automated service at the other ISPs along with the CERT which then builds the filters based on that information after verifying the CERTs authenticity. Now all of the above is completely automatable including the CERT generation. Yes, it requires someone to write a implementation and integrate it with the existing systems. > I don't think any of this is rocket science, but it apparently is a > real block to BCP38/84 implementatin. No, this isn't rocket science. It just requires a little co-ordination. > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From alvarezp at alvarezp.ods.org Wed Feb 5 00:48:30 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 04 Feb 2014 16:48:30 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: References: Message-ID: <52F18A5E.8050803@alvarezp.ods.org> On 04/02/14 16:31, Livingood, Jason wrote: >>> Can somebody explain to me why those who run eyeball networks are able >>> to block outbound packets when the customer hasn't paid their bill, >>> but can't seem to block packets that shouldn't be coming from that >>> cablemodem? >> >> i suspect the non-payment case is solved at a layer below three > > In a DOCSIS network the source address verification (as Tony said) is > typically done on the CMTS IIRC. Turning a customer off for non-payment is > done in an accounts management / billing system. > > While I am sure continuing to agree with each other that spoofing is bad, > we lack actionable data. ;-) As I said in another thread, I think someone > / some group needs to invest to collect actual data and share the results > openly. > > So any volunteers out there? I?m sure there are lots of ways to underwrite > independent research on the subject (contact me off-list). Maybe I'm oversimplifying things but I'm really curious to know why can't the nearest-to-end-user ACL-enabled router simply have an ACL to only allows packets from end-users that has a valid source-address from the network segment they provide service to. What I'm failing to understand, and again, please excuse me if I'm oversimplifying, is what data do you need from researchers, specifically. What specific actionable data would be helpful? Why does the lack of the data prevent you from applying an ACL. From Jason_Livingood at cable.comcast.com Wed Feb 5 00:53:17 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 5 Feb 2014 00:53:17 +0000 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <52F18A5E.8050803@alvarezp.ods.org> Message-ID: On 2/4/14, 7:48 PM, "Octavio Alvarez" wrote: >What I'm failing to understand, and again, please excuse me if I'm >oversimplifying, is what data do you need from researchers, >specifically. What specific actionable data would be helpful? Why does >the lack of the data prevent you from applying an ACL. What I am suggesting is that the community at large needs measurement data, rather than individual network operators (which already know if they do or do not implement BCP38). Only with a long list of operators that DO prevent spoofing and a list of those that DO NOT, backed up with a decent data set (enough measurement points, enough measurement tests, across enough time, with an openly shared methodology), can the community start to encourage non-adopters to change their position. Just my two cents though... Jason From john at west-canaan.net Wed Feb 5 01:06:39 2014 From: john at west-canaan.net (John Zettlemoyer) Date: Tue, 4 Feb 2014 20:06:39 -0500 Subject: Cogent <-> Verizon peering congestion Message-ID: I got that same response from Cogent in August and October when we complained (word for word). Sometimes it's bad, sometimes it's "ok". Happens with Comcast sometimes too, but the peer to Verizon is usually worse. I can show packet loss with an MTR anytime of day. Today is an "ok" day.... just 5% loss on average. |------------------------------------------------------------------------------------------| | MTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | gw2-j.phl1.wcit.net - 0 | 101 | 101 | 1 | 6 | 98 | 2 | | gi3-6.ccr01.phl05.atlas.cogentco.com - 0 | 101 | 101 | 1 | 17 | 179 | 16 | | te7-4.ccr01.phl01.atlas.cogentco.com - 0 | 101 | 101 | 1 | 31 | 205 | 1 | | te4-1.ccr01.bwi01.atlas.cogentco.com - 0 | 101 | 101 | 3 | 34 | 192 | 3 | |te0-1-0-7.mpd21.dca01.atlas.cogentco.com - 0 | 101 | 101 | 5 | 6 | 11 | 6 | | be2113.ccr41.iad02.atlas.cogentco.com - 0 | 101 | 101 | 6 | 6 | 12 | 7 | | verizon.iad01.atlas.cogentco.com - 5 | 85 | 81 | 0 | 48 | 95 | 47 | | No response from host - 100 | 21 | 0 | 0 | 0 | 0 | 0 | | l100.cmdnnj-vfttp-01.verizon-gni.net - 5 | 85 | 81 | 55 | 62 | 136 | 56 | |________________________________________________|______|______|______|______|______|______| ? John Zettlemoyer From edwardroels at gmail.com Wed Feb 5 01:08:30 2014 From: edwardroels at gmail.com (Edward Roels) Date: Tue, 4 Feb 2014 20:08:30 -0500 Subject: Cogent <-> Verizon peering congestion In-Reply-To: <52F17B4E.20808@garlic.com> References: <52F17B4E.20808@garlic.com> Message-ID: Cogent support uses the same response when inquiring about Comcast, CenturyLink, Tata, AT&T etc. If the "Tier 1s" are really keeping each other congested, are they not creating an environment where you have to buy from each of them to have a chance at congestion free paths? Or peer around them. On Tue, Feb 4, 2014 at 6:44 PM, Robert Glover wrote: > Hello, > > For the last several months, we have been tracking a congestion issue > between Cogent <-> Verizon > > Host Loss% Snt Last Avg Best Wrst StDev > 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 > 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 > 161.1 29.5 > 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 > 2.4 3.6 0.2 > 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 > 4.8 0.2 > 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 > 5.5 0.3 > 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 > 6.9 > 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 > 171.6 271.6 24.8 > 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 > 171.7 250.8 18.3 > 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 > 195.5 199.2 0.8 > > We have smokeping's from our side showing 30%+ packet loss from us > (AS4307) to Verizon. > > All I have gotten from Cogent is a canned response: > > --- > The latency and/or packet loss that you are experiencing to this > destination is due to occasional high traffic with Verizon. We have > repeatedly requested augments to these congestion points and hope Verizon > will comply soon. While this has been escalated internally to the CEO > level, we encourage you to also contact Verizon customer support with your > concerns and complaints. Their delay is a major impediment to internet > traffic overall and contrary to net neutrality requirements. Our peering > engineers will continue to address this on a daily basis until resolved. > --- > > It seems to have gotten a lot worse in recent days, to the point where we > have customers who are trying to access us from Verizon's network (i.e. > they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having > a very hard to checking their email, etc. > > Has anyone else been experiencing these issues? Or does anyone have more > information that what Cogent provided me in their canned statement? > > -Bobby > > From jra at baylink.com Wed Feb 5 01:08:36 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Feb 2014 20:08:36 -0500 (EST) Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140205002905.57856.qmail@joyce.lan> Message-ID: <29420711.7272.1391562516194.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Levine" > Subject: Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? > >Why does it have to be hard? Restricting the filter to addresses > >which > >(A) the customer asserts are theirs > > How does the customer do that in a way that scales? > > I don't think any of this is rocket science, but it apparently is a > real block to BCP38/84 implementatin. Well, there are two issues: how many exceptions at the transit layer will actually be needed, in practice... and how much trouble will there still be there if we can get appreciable uptake at the edge? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From randy at psg.com Wed Feb 5 01:13:41 2014 From: randy at psg.com (Randy Bush) Date: Wed, 05 Feb 2014 10:13:41 +0900 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140205004806.C3F97E542B1@rock.dv.isc.org> References: <20140205002905.57856.qmail@joyce.lan> <20140205004806.C3F97E542B1@rock.dv.isc.org> Message-ID: >> How does the customer do that in a way that scales? > You implement SIDR to the extent where you issue your multi homed > customers CERTs for the address space you allocated to them. The > customer can then just send signed requests to a automated service > at the other ISPs along with the CERT which then builds the filters > based on that information after verifying the CERTs authenticity. you have done this in your network, the isp for which you are an engineer? randy From marka at isc.org Wed Feb 5 01:18:54 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Feb 2014 12:18:54 +1100 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: Your message of "Tue, 04 Feb 2014 18:35:13 -0500." <52F17931.40604@alter3d.ca> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> Message-ID: <20140205011854.7C1B8E548F3@rock.dv.isc.org> In message <52F17931.40604 at alter3d.ca>, Peter Kristolaitis writes: > On 2/4/2014 5:00 PM, Mark Andrews wrote: > >> Nope: it's easy to explain; you merely have to be a cynical bastard: > >> > >> Attack traffic takes up bandwidth. > >> > >> Providers sell bandwidth. > >> > >> It *is in their commercial best interest (read: maximizing shareholder > >> value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is > >> forced -- it's actually their fiduciary duty not to. > > Then the need to be made criminally liable for the damage that it causes. > > Yes, the directors of these companies need to serve gaol time. > > That would never fly, because it would put the politicians at odds with > the telecom buddies that make huge political donations. Hard to throw > someone in jail then hit them up for campaign money. What will > probably happen is the same thing we do with everything else that might > be used for evil purposes but where we don't want to tackle the real > underlying problem -- just write a law banning something and hope the > problem goes away. No, you write a law requiring something, e.g. BCP 38 filtering by ISPs, and you audit it. You also make the ISPs directors liable for the impact that results from spoofed traffic from them. Making it law puts all the ISP's in the country on a equal footing with respect to implementation costs. > Make it illegal to posses a device capable of bandwith greater than > 33.6Kbps without a special license, and BAM -- no more problems, > overnight. For added political-style points, tack on a catchy moniker, > like "Immoral Bandwidth Prohibition", "The War on DDOS", or > "High-Capacity Digital Assault Bandwidth" to help sell it to the > public. The public will be OK with their funny cat videos taking 19 > hours to load if they know they're preventing bad guys from doing > something evil. If you have millions of compromised customers it doesn't matter what bandwidth limits they have. You can still launch a amplifying reflection DDoS from hosts behind 300 baud links. > After all, it's worked flawlessly for alcohol, drugs and guns, so it > MUST work for networks... and it's much easier than those silly, > so-called "solutions" y'all are talking about! :p Regulation and audits works well enough for butchers, resturants etc. Remember once BCP 38 is implemented it is relatively easy to continue. The big step is getting it turned on in the first place which requires having the right equipment. Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. > - Pete > > (P.S. Dear politicians: in case you're reading this, the above was > satire and should not be construed as anything resembling a good idea.) > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From robertg at garlic.com Wed Feb 5 01:33:40 2014 From: robertg at garlic.com (Robert Glover) Date: Tue, 04 Feb 2014 17:33:40 -0800 Subject: Cogent <-> Verizon peering congestion In-Reply-To: <52F17B4E.20808@garlic.com> References: <52F17B4E.20808@garlic.com> Message-ID: <52F194F4.9040106@garlic.com> FYI, here's the latest response from Cogent when I prodded them about the issue (just received this about 30 minutes ago: --- The issue on this peer involves a high amount of traffic being sent to Cogent from the Verizon network. In order to resolve the congestion on that peer, Verizon needs to engineer thier routing to another peering point with Cogent that has more available space for the traffic. We have reached out to Verizon for assistance and are still awaiting a response from their peering engineers. We will continue to reach out to them until they respond. --- Sounds like more "fluff" to me :-/ -Bobby From cgucker at onesc.net Wed Feb 5 01:40:30 2014 From: cgucker at onesc.net (Charles Gucker) Date: Tue, 4 Feb 2014 20:40:30 -0500 Subject: Cogent <-> Verizon peering congestion In-Reply-To: References: <52F17B4E.20808@garlic.com> Message-ID: Just to make something clear. I do not own any stock, interest or have any official relationship with Verizon or Cogent. The opinions expressed are mine and mine alone as I have come to understand some of the relationship without the aid of any privileged information. On Tue, Feb 4, 2014 at 8:08 PM, Edward Roels wrote: > Cogent support uses the same response when inquiring about Comcast, > CenturyLink, Tata, AT&T etc. Yup, certainly a common thread there. It wouldn't take a lot of digging to determine that those "peers" are most likely compensated in some way shape or form. Hence the lack of response by the remote "peer" to upgrade what would most likely be a paid peer. > If the "Tier 1s" are really keeping each other congested, are they not > creating an environment where you have to buy from each of them to have a > chance at congestion free paths? Or peer around them. The term tier 1 is a marketing term. The last time I looked Cogent was default free, but certainly not settlement free. Good luck peering around a lot of the networks in which they have congestion from. The only real way would be to order additional capacity, buy transit or live with the situation long enough for customers complain to the remote network. If that doesn't work then force a partition with the end objective of Cogent to change from a compensated peer to a settlement free peer. It's a fun game, it's unfortunate that customer flows have to be used to force it. Let me help translate the canned response. >> All I have gotten from Cogent is a canned response: >> >> --- >> The latency and/or packet loss that you are experiencing to this >> destination is due to occasional high traffic with Verizon. We are sorry that we transmit more traffic to Verizon than we are willing to pay Verizon for. >> We have >> repeatedly requested augments to these congestion points and hope Verizon >> will comply soon. We have demanded that the compensated peers be converted to settlement free peers with greater capacity, with little to no response. >> While this has been escalated internally to the CEO >> level, we encourage you to also contact Verizon customer support with your >> concerns and complaints. Our CEO is aware that this will cost money but is unwilling to pay for additional bandwidth, so we are in a stalemate and want customers to complain to Verizon in the hopes that the squeaky wheel will get the grease or in other terms, free capacity. >> Their delay is a major impediment to internet >> traffic overall and contrary to net neutrality requirements. Since the connectivity is compensated, Verizon refuses to provide additional bandwidth at an acceptable (free) cost. So, no money equals no additional customer capacity. >> Our peering >> engineers will continue to address this on a daily basis until resolved. Our peering folks will continue to pester Verizon's non-commercial folks by requesting settlement free peers but until enough people complain to Verizon the requests will fall on deaf ears. thanks, charles From randy at psg.com Wed Feb 5 01:40:55 2014 From: randy at psg.com (Randy Bush) Date: Wed, 05 Feb 2014 10:40:55 +0900 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140205011854.7C1B8E548F3@rock.dv.isc.org> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> Message-ID: > No, you write a law requiring something, e.g. BCP 38 filtering by > ISPs, and you audit it. You also make the ISPs directors liable > for the impact that results from spoofed traffic from them. > > Making it law puts all the ISP's in the country on a equal footing > with respect to implementation costs. you have done this in your network, the isp for which you are an engineer? randy From jamesl at mythostech.com Wed Feb 5 01:43:35 2014 From: jamesl at mythostech.com (James Laszko) Date: Wed, 5 Feb 2014 01:43:35 +0000 Subject: Cogent <-> Verizon peering congestion In-Reply-To: <52F194F4.9040106@garlic.com> References: <52F17B4E.20808@garlic.com>,<52F194F4.9040106@garlic.com> Message-ID: <9E495C9A-EE42-41C8-A98B-978AE740C301@mythostech.com> He received a very similar response from Level3 when we complained to them about the issue. "We have contacted VZ with no response" We see pings go from 8ms to 110ms+ from our office FIOS to one of our data centers in San Diego.... LAX handoffs of FIOS traffic to Cogent & Level3 appears the choke points to us. James Laszko Mythos Technlogy Inc jamesl at mythostech.com Sent from my iPhone > On Feb 4, 2014, at 5:35 PM, "Robert Glover" wrote: > > FYI, here's the latest response from Cogent when I prodded them about > the issue (just received this about 30 minutes ago: > > --- > The issue on this peer involves a high amount of traffic being sent to > Cogent from the Verizon network. In order to resolve the congestion on > that peer, Verizon needs to engineer thier routing to another peering > point with Cogent that has more available space for the traffic. We have > reached out to Verizon for assistance and are still awaiting a response > from their peering engineers. We will continue to reach out to them > until they respond. > --- > > Sounds like more "fluff" to me :-/ > > -Bobby > From brian at aereo.com Wed Feb 5 02:41:14 2014 From: brian at aereo.com (Brian Loveland) Date: Tue, 4 Feb 2014 21:41:14 -0500 Subject: Verizon Fios Issue in Massachusetts Message-ID: Is anyone from Verizon available to help me chase down an issue off-list? Since Sunday morning, we've been seeing what looks to be a bad link aggregation (10+% packet loss on one IP, 0% on an adjacent IP) to all of the networks we control (on various providers, various AS's, various locations) and to common things like 8.8.8.8 and 8.8.4.4 from my Fios connection at home. Colleagues are seeing the same from other towns in MA. A couple of them have opened tickets with Fios support but haven't gotten anywhere. Unfortunately not a AS701 IP customer for our work networks, so can't follow normal support channels on that side. Thanks. From jhaas at pfrc.org Wed Feb 5 03:53:40 2014 From: jhaas at pfrc.org (Jeffrey Haas) Date: Tue, 4 Feb 2014 22:53:40 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <52E40476.20200@foobar.org> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> Message-ID: <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> Sent from my iPad > On Jan 25, 2014, at 1:37 PM, Nick Hilliard wrote: > >> On 25/01/2014 15:48, Sebastian Spies wrote: >> To make things worse: even if the IXPs ASN is 2-byte, I would assume, >> that RS implementors chose to interpret extended community strings as >> always being in the format 4-byte:2-byte (see RFC5668). > > some ixp operators (e.g. me) are rather enthusiastic about the idea of a > modified form of draft-raszuk-wide-bgp-communities getting more traction. > This would solve this particular problem and many others. > Wide communities is the wrong tool here. You want this: http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06 -- Jeff > Nick > From jhaas at pfrc.org Wed Feb 5 03:58:43 2014 From: jhaas at pfrc.org (Jeffrey Haas) Date: Tue, 4 Feb 2014 22:58:43 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F670C5@eusaamb109.ericsson.se> Message-ID: <5AFAC211-6434-484B-B1A7-DA7FA3A6E759@pfrc.org> Sent from my iPad On Jan 25, 2014, at 5:50 PM, Randy Bush wrote: >> http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03 >> To me, that draft looks hugely complicated, like everything you >> could possibly think of was thrown in. > > > > do we have a chat with robert or push an alternative so that the wg is > pushed to compromise? > The token to simplify is currently mine. The messy bit was an attempt to try to push policy algebra into the packet format. A hallway conversation with a certain German gentleman helped disabuse me about the wisdom of doing that. Cleaning up the document will take probably another two rounds but a terse description of where it should be going is "template based structured communities". -- Jeff > randy From Valdis.Kletnieks at vt.edu Wed Feb 5 04:01:32 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Feb 2014 23:01:32 -0500 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: Your message of "Wed, 05 Feb 2014 12:18:54 +1100." <20140205011854.7C1B8E548F3@rock.dv.isc.org> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> Message-ID: <16144.1391572892@turing-police.cc.vt.edu> On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: > Regulation and audits works well enough for butchers, resturants > etc. Remember once BCP 38 is implemented it is relatively easy to > continue. The big step is getting it turned on in the first place > which requires having the right equipment. > > Now if we could get equipement vendors to stop shipping models > without the necessary support it would help but that also may require > government intervention. Time to name-and-shame. It's 2014. Who's still shipping gear that can't manage eyeball-facing BCP38? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From frnkblk at iname.com Wed Feb 5 04:03:04 2014 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 4 Feb 2014 22:03:04 -0600 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: References: <52F18A5E.8050803@alvarezp.ods.org> Message-ID: <005001cf2227$2b9c3480$82d49d80$@iname.com> Here's such a report: http://spoofer.cmand.org/summary.php Frank -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] Sent: Tuesday, February 04, 2014 6:53 PM To: Octavio Alvarez; North American Network Operators' Group Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] On 2/4/14, 7:48 PM, "Octavio Alvarez" wrote: >What I'm failing to understand, and again, please excuse me if I'm >oversimplifying, is what data do you need from researchers, >specifically. What specific actionable data would be helpful? Why does >the lack of the data prevent you from applying an ACL. What I am suggesting is that the community at large needs measurement data, rather than individual network operators (which already know if they do or do not implement BCP38). Only with a long list of operators that DO prevent spoofing and a list of those that DO NOT, backed up with a decent data set (enough measurement points, enough measurement tests, across enough time, with an openly shared methodology), can the community start to encourage non-adopters to change their position. Just my two cents though... Jason From davey at latte.net.nz Wed Feb 5 05:47:59 2014 From: davey at latte.net.nz (Davey Goode) Date: Tue, 4 Feb 2014 21:47:59 -0800 Subject: MMF optics for Juniper EX4550 Message-ID: Hi All, Can anyone recommend where to get some 10G SFP+ MMF optics what will work in a Juno. Im in San Jose right now and I'm flying back to NZ on friday.... replies off list would be appreciated. thanks in advanced. davey From mysidia at gmail.com Wed Feb 5 07:12:40 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Feb 2014 01:12:40 -0600 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <16144.1391572892@turing-police.cc.vt.edu> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> Message-ID: On Tue, Feb 4, 2014 at 10:01 PM, wrote: > On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: > > Now if we could get equipement vendors to stop shipping models > > without the necessary support it would help but that also may require > > government intervention. > A good start would be to get BCP38 revised to router the Host requirements RFCs, to indicate that ingress filtering should be considered mandatory on site-facing interfaces. If the standards documents still just call it a best practice.... what hope is there of having governments require it of the service providers that their networks are connected to, anyways? > > Time to name-and-shame. It's 2014. Who's still shipping gear that > can't manage eyeball-facing BCP38? > -- -JH From sh.vahabzadeh at gmail.com Wed Feb 5 07:34:55 2014 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Wed, 5 Feb 2014 11:04:55 +0330 Subject: Cisco 7606 CPU Usage Problem Message-ID: Hi there, I have a Cisco 7606 with this module on it: WS-SUP32-GE-3B and I am using its own 8 port like this: 2 Port Layer two ether-channel uplink to my 4900 Cisco Switch and 1 Layer two uplink to Internet, and near 10 tunnel to my customers for internet exchange with BGP peering + some policy map for shaping tunnel interfaces. My ether-channel traffic on 600Mbps (each port 300Mbps) I get 90% cpu load and ping time problem on my router, what is the problem?? And when I run: show processs cpu sorted I get a "Unknown" process eat the cpu process... I try lots of IOS version but it does not make difference. My IOS version is: c7600s3223-adventerprisek9-mz.150-1.S1.bin and some general configuration: no ip source-route > ! > ip cef load-sharing algorithm original > no ip domain lookup > ! > ! > ! > ! > mls ip cef load-sharing full > no mls flow ip > no mls flow ipv6 > mls qos > mls cef error action reset > multilink bundle-name authenticated > ! > spanning-tree mode pvst > spanning-tree extend system-id > system flowcontrol bus auto > diagnostic bootup level minimal > port-channel load-balance src-ip > username admin secret 5 $1$g6WX$LaQbPyD3qIaHsF5qTqt8g0 > ! > redundancy > main-cpu > auto-sync running-config > mode sso > ! > ! > ! > ! > vlan internal allocation policy ascending > vlan access-log ratelimit 2000 Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From saku at ytti.fi Wed Feb 5 08:35:07 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 5 Feb 2014 10:35:07 +0200 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140205002905.57856.qmail@joyce.lan> References: <20140205002905.57856.qmail@joyce.lan> Message-ID: <20140205083507.GA20473@pob.ytti.fi> On (2014-02-05 00:29 -0000), John Levine wrote: > >Why does it have to be hard? Restricting the filter to addresses which > >(A) the customer asserts are theirs > > How does the customer do that in a way that scales? > > I don't think any of this is rocket science, but it apparently is a > real block to BCP38/84 implementatin. Transit provider can do ACL, in some platforms it can be 100% same object as used for BGP. Then setup ultimate rule to allow and log. Then cooperate with customer to weed through the unexpected, until none remain and flip the allow to deny. But I guess no one is saying it cannot be done, more that there is no pay-off in it. Transit provider is compensated for bits transferred, spending money to receive less money may not appeal to people in charge. You also wrote: >>I was at a conference with people from some Very Large ISPs. They >>told me that many of their large customers absolutely will not let >>them do BCP38 filtering. ("If you don't want our business, we can >>find someone else who does.") The usual problem is that they have PA >>space from two providers and for various reasons, not all of which are >>stupid, traffic with provider A's addresses sometimes goes out through >>provider B. Adding to the excitement, some of these customers are >>medium sized ISPs with multihomed customers of their own. Someone who worked for such ISP, told they don't accept BCP38, because their business is to sell services to instances who want to spoof for what ever reason. The official reasons told to upstreams are different. He didn't appreciate the business and no longer works for said ISP. If what you say was actual reason, it could be solved by logging ACL. We the community, could produce tooling to automate this in few popular platforms. Automatically builds the ACL, web interface for humans to classify the logged/unknown. When classified by human as legit source, automatically create route object for it. Recreate ACL from route-objects, submit to router. Repeat until human operator is confident no further classification is needed, and ask tool to swap log+permit + deny. Probably takes like maybe 50h development work. -- ++ytti, not it From saku at ytti.fi Wed Feb 5 08:46:57 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 5 Feb 2014 10:46:57 +0200 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <16144.1391572892@turing-police.cc.vt.edu> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> Message-ID: <20140205084657.GA22744@pob.ytti.fi> On (2014-02-04 23:01 -0500), Valdis.Kletnieks at vt.edu wrote: > > Regulation and audits works well enough for butchers, resturants > > etc. Remember once BCP 38 is implemented it is relatively easy to > > continue. The big step is getting it turned on in the first place > > which requires having the right equipment. > > > > Now if we could get equipement vendors to stop shipping models > > without the necessary support it would help but that also may require > > government intervention. > > Time to name-and-shame. It's 2014. Who's still shipping gear that > can't manage eyeball-facing BCP38? If we keep thinking this problem as last-mile port problem, it won't be solved in next 20 years. Because lot of those ports really can't do RPF and even if they can do it, they are on autopilot and next change is market forced fork-lift change. Company may not even employ technical personnel, only buy consulting when making changes. If we focus on transit borders, we can make spoofed DoS completely impractical very rapidly, as spoofing is then restricted inside domain, and if target isn't in same domain, you can't benefit from it. And as attacks are from distributed botnets, you'll simply generate more attack traffic by not spooffing, as you're not restricted inside spooffing domain. However transit border doing ACL is something that seems to very controversial, there is no universal consensus that it even should be done and quite few seem to do it. I feel we need to change this, and make community at large agree it is the BCP and solve the challenges presented. -- ++ytti From martin.pels at ams-ix.net Wed Feb 5 09:06:31 2014 From: martin.pels at ams-ix.net (Martin Pels) Date: Wed, 5 Feb 2014 10:06:31 +0100 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> Message-ID: <20140205100631.479da729@fizzix> Jeffrey, On Tue, 4 Feb 2014 22:53:40 -0500 Jeffrey Haas wrote: > > > Sent from my iPad > > > On Jan 25, 2014, at 1:37 PM, Nick Hilliard wrote: > > > >> On 25/01/2014 15:48, Sebastian Spies wrote: > >> To make things worse: even if the IXPs ASN is 2-byte, I would assume, > >> that RS implementors chose to interpret extended community strings as > >> always being in the format 4-byte:2-byte (see RFC5668). > > > > some ixp operators (e.g. me) are rather enthusiastic about the idea of a > > modified form of draft-raszuk-wide-bgp-communities getting more traction. > > This would solve this particular problem and many others. > > > > Wide communities is the wrong tool here. You want this: > http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06 This draft does not cater for the use case of describing a 32-bit ASN peering with a 32-bit route server, which would require a 4-byte Global Administrator as well as a 4-byte Local Administrator sub-field. Kind regards, Martin From randy at psg.com Wed Feb 5 10:46:32 2014 From: randy at psg.com (Randy Bush) Date: Wed, 05 Feb 2014 19:46:32 +0900 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <5AFAC211-6434-484B-B1A7-DA7FA3A6E759@pfrc.org> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F670C5@eusaamb109.ericsson.se> <5AFAC211-6434-484B-B1A7-DA7FA3A6E759@pfrc.org> Message-ID: > The token to simplify is currently mine. The messy bit was an attempt > to try to push policy algebra into the packet format. jeezus! > Cleaning up the document will take probably another two rounds but a > terse description of where it should be going is "template based > structured communities". second system syndrome From arturo.servin at gmail.com Wed Feb 5 11:30:47 2014 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 5 Feb 2014 11:30:47 +0000 Subject: BCP38.info In-Reply-To: <52E8D509.8020008@isoc.org> References: <939fe1a$25013901$31ba95f6$@flhsi.com> <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net> <52E8D509.8020008@isoc.org> Message-ID: Not working in the Internet access business but as Internet citizen this sounds interesting. You would need some motivations to make ISPs register and perhaps some kind of validation in the future. But as initial step it sounds cool. .as On Wed, Jan 29, 2014 at 10:16 AM, Andrei Robachevsky wrote: > Hi, > > Jared Mauch wrote on 1/28/14 9:03 PM: >> I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network. > > At the Internet Society we are flashing out an idea of an anti-spoofing > "movement", where ISPs can list themselves as not spoofing-capable on > our website. The requirement is that they can demonstrate that they > block spoofed packets, for instance by successfully running the Spoofer > test. I think your, Jared, test can add to this picture. > > Sort of a positive spin on the name and shame technique. > > It is not ideal, as one test is not a real proof of such capability, but > might help raising awareness, at least. Does this sound as something > that can be useful and fly? From shawnl at up.net Wed Feb 5 13:24:50 2014 From: shawnl at up.net (Shawn L) Date: Wed, 5 Feb 2014 08:24:50 -0500 Subject: Cisco 7606 CPU Usage Problem In-Reply-To: References: Message-ID: We had some similar issues whenever the BGP scanner process was running. Ultimately we tracked down the issue to an access list that had the 'log' statement appended to it, so it was logging all denies. Removing that cleared up the issue. On Wed, Feb 5, 2014 at 2:34 AM, Shahab Vahabzadeh wrote: > Hi there, > I have a Cisco 7606 with this module on it: > > WS-SUP32-GE-3B > > > and I am using its own 8 port like this: > > 2 Port Layer two ether-channel uplink to my 4900 Cisco Switch and 1 Layer > two uplink to Internet, and near 10 tunnel to my customers for internet > exchange with BGP peering + some policy map for shaping tunnel interfaces. > My ether-channel traffic on 600Mbps (each port 300Mbps) I get 90% cpu load > and ping time problem on my router, what is the problem?? > And when I run: show processs cpu sorted > I get a "Unknown" process eat the cpu process... > I try lots of IOS version but it does not make difference. > > My IOS version is: > > c7600s3223-adventerprisek9-mz.150-1.S1.bin > > > > and some general configuration: > > no ip source-route > > ! > > ip cef load-sharing algorithm original > > no ip domain lookup > > ! > > ! > > ! > > ! > > mls ip cef load-sharing full > > no mls flow ip > > no mls flow ipv6 > > mls qos > > mls cef error action reset > > multilink bundle-name authenticated > > ! > > spanning-tree mode pvst > > spanning-tree extend system-id > > system flowcontrol bus auto > > diagnostic bootup level minimal > > port-channel load-balance src-ip > > username admin secret 5 $1$g6WX$LaQbPyD3qIaHsF5qTqt8g0 > > ! > > redundancy > > main-cpu > > auto-sync running-config > > mode sso > > ! > > ! > > ! > > ! > > vlan internal allocation policy ascending > > vlan access-log ratelimit 2000 > > > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > From jhaas at pfrc.org Wed Feb 5 13:52:03 2014 From: jhaas at pfrc.org (Jeffrey Haas) Date: Wed, 5 Feb 2014 08:52:03 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <20140205100631.479da729@fizzix> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> <20140205100631.479da729@fizzix> Message-ID: <20140205135203.GA594@pfrc> Martin, On Wed, Feb 05, 2014 at 10:06:31AM +0100, Martin Pels wrote: > > Wide communities is the wrong tool here. You want this: > > http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06 > > This draft does not cater for the use case of describing a 32-bit ASN peering > with a 32-bit route server, which would require a 4-byte Global Administrator > as well as a 4-byte Local Administrator sub-field. I think that's the first clear articulation I've read about why some people want wide comms vs. a simple replacement for existing regular communities as extended communities. Thanks. Wide comms can do that, but they're intended to be a somewhat bigger hammer. This case is probably worth chatting with the authors and others in IDR at IETF to see if we should do something simpler. -- Jeff From jared at puck.nether.net Wed Feb 5 14:02:52 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 5 Feb 2014 09:02:52 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <20140205135203.GA594@pfrc> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> <20140205100631.479da729@fizzix> <20140205135203.GA594@pfrc> Message-ID: On Feb 5, 2014, at 8:52 AM, Jeffrey Haas wrote: >> This draft does not cater for the use case of describing a 32-bit ASN peering >> with a 32-bit route server, which would require a 4-byte Global Administrator >> as well as a 4-byte Local Administrator sub-field. > > I think that's the first clear articulation I've read about why some people > want wide comms vs. a simple replacement for existing regular communities as > extended communities. Thanks. I suspect the operator confusion is that?s how they?ve been using 16-bit ASNs all along, so how did the IETF end up with something different. http://www.onesc.net/communities/ is a fairly comprehensive list of how they are used today. - jared From jhaas at pfrc.org Wed Feb 5 14:21:59 2014 From: jhaas at pfrc.org (Jeffrey Haas) Date: Wed, 5 Feb 2014 09:21:59 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: References: <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> <20140205100631.479da729@fizzix> <20140205135203.GA594@pfrc> Message-ID: <20140205142159.GB594@pfrc> On Wed, Feb 05, 2014 at 09:02:52AM -0500, Jared Mauch wrote: > > On Feb 5, 2014, at 8:52 AM, Jeffrey Haas wrote: > > >> This draft does not cater for the use case of describing a 32-bit ASN peering > >> with a 32-bit route server, which would require a 4-byte Global Administrator > >> as well as a 4-byte Local Administrator sub-field. > > > > I think that's the first clear articulation I've read about why some people > > want wide comms vs. a simple replacement for existing regular communities as > > extended communities. Thanks. > > I suspect the operator confusion is that?s how they?ve been using 16-bit ASNs > all along, so how did the IETF end up with something different. > > http://www.onesc.net/communities/ is a fairly comprehensive list of how they are used today. Thanks for the list. Browsing the first several entries somewhat supports the reason why I'm acting "surprised". While there are some cases where the right hand side of the community is an AS number, a significant amount of it was either an arbitrary value or something more structured. The generic 4-byte draft I'm part of is intended to be "low hanging fruit". We don't need to deploy a new attribute, the format specifier is already present in code. All that was needed was a code point to say "go use this like existing RFC 1997 comms". The wide comms draft (and flex comms, where some of the ideas were pulled in from) was intended to address the messier case where the meaning of a community was already structured. To pick on one of the items in the list: http://www.onesc.net/communities/as209/ Coding these using regexes is a PITA, both as an implementor of the underlying policy and as a sender who has to remember what the magic value means. Ideally the operator should end up with something simple: Tell AS209, Do not announce to AS foo. Prepend N times to PST peers. Etc. Right now, these things are magic values. The last few rounds of wide comms were attempts to get encoding formats in place that accommodated some amount of grouping logic (peer-class CUSTOMER & North America, e.g.). We did manage to work out a way to do that encoding correctly. But it turned out that the real killer was transitive manipulation - you can't meddle with such a thing without breaking logic. So, back to a simpler drawing board. An update to the wide-comm draft should be out by end of this week. We'd welcome some constructive criticism on it. -- Jeff From bbridges at springnet.net Wed Feb 5 16:04:20 2014 From: bbridges at springnet.net (Ben Bridges) Date: Wed, 5 Feb 2014 16:04:20 +0000 Subject: Cogent <-> Verizon peering congestion In-Reply-To: <52F17B4E.20808@garlic.com> References: <52F17B4E.20808@garlic.com> Message-ID: We've been having trouble with congestion between Verizon and Cogent in Chicago since May 2013. We had to move some traffic off of our Verizon connection to get around it. Verizon has apparently had an internal ticket open for the problem since February 2013. Their response in August 2013 was "Cogent is designing an upgrade to turn up the bandwidth". Their response a few weeks ago was "Verizon is working with Cogent on increasing more capacity there is no deadline of completion, issue ongoing since 2013 possible completion in 2014". In other words, they're blaming Cogent. Ben Bridges SpringNet -----Original Message----- From: Robert Glover [mailto:robertg at garlic.com] Sent: Tuesday, February 04, 2014 5:44 PM To: nanog at nanog.org Subject: Cogent <-> Verizon peering congestion Hello, For the last several months, we have been tracking a congestion issue between Cogent <-> Verizon Host Loss% Snt Last Avg Best Wrst StDev 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 161.1 29.5 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 2.4 3.6 0.2 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 4.8 0.2 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 5.5 0.3 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 6.9 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 171.6 271.6 24.8 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 171.7 250.8 18.3 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 195.5 199.2 0.8 We have smokeping's from our side showing 30%+ packet loss from us (AS4307) to Verizon. All I have gotten from Cogent is a canned response: --- The latency and/or packet loss that you are experiencing to this destination is due to occasional high traffic with Verizon. We have repeatedly requested augments to these congestion points and hope Verizon will comply soon. While this has been escalated internally to the CEO level, we encourage you to also contact Verizon customer support with your concerns and complaints. Their delay is a major impediment to internet traffic overall and contrary to net neutrality requirements. Our peering engineers will continue to address this on a daily basis until resolved. --- It seems to have gotten a lot worse in recent days, to the point where we have customers who are trying to access us from Verizon's network (i.e. they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having a very hard to checking their email, etc. Has anyone else been experiencing these issues? Or does anyone have more information that what Cogent provided me in their canned statement? -Bobby From jared at puck.nether.net Wed Feb 5 16:04:26 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 5 Feb 2014 11:04:26 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <20140205142159.GB594@pfrc> References: <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> <20140205100631.479da729@fizzix> <20140205135203.GA594@pfrc> <20140205142159.GB594@pfrc> Message-ID: On Feb 5, 2014, at 9:21 AM, Jeffrey Haas wrote: > The wide comms draft (and flex comms, where some of the ideas were pulled in > from) was intended to address the messier case where the meaning of a > community was already structured. To pick on one of the items in the list: > http://www.onesc.net/communities/as209/ > > Coding these using regexes is a PITA, both as an implementor of the > underlying policy and as a sender who has to remember what the magic value > means. Ideally the operator should end up with something simple: > Tell AS209, Do not announce to AS foo. Prepend N times to PST peers. Etc. > Right now, these things are magic values. When possible (e.g.: here at AS2914) we have used things like this: 65500:nnn do not announce to peer where the NNN is the peer ASN. Using such literal numbering is easier for the humans involved. The ability to see what route is learned from specific ASN is also helpful, as things like AS_PATH are just a bit-string that can be arbitrarily set and sent by a peer. I will try to keep my eye open for the draft. (perhaps see you in Atlanta or London). - Jared From jared at puck.nether.net Wed Feb 5 16:15:25 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 5 Feb 2014 11:15:25 -0500 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <20140205083507.GA20473@pob.ytti.fi> References: <20140205002905.57856.qmail@joyce.lan> <20140205083507.GA20473@pob.ytti.fi> Message-ID: <11FCB9B4-E44D-40C2-9BE4-5045208658D1@puck.nether.net> On Feb 5, 2014, at 3:35 AM, Saku Ytti wrote: > If what you say was actual reason, it could be solved by logging ACL. > > We the community, could produce tooling to automate this in few popular > platforms. Automatically builds the ACL, web interface for humans to classify > the logged/unknown. When classified by human as legit source, automatically > create route object for it. > Recreate ACL from route-objects, submit to router. The problem is many of these can compile to larger than the physical amount of space in the router/LC have to handle it. I?ve done presentations to vendors about what percentage (in bytes and per-line) of the configuration is of what component. 90%+ tends to be customer-specific prefix-list/set/filter lines. These can easily reach many megabytes of configuration and tens or hundreds of thousands of lines. Asking someone to duplicate that to also have an ingress ACL of equivalent size, and *assuming* the router can handle that ACL and compile it properly is a challenge to say the least. > Repeat until human operator is confident no further classification is needed, > and ask tool to swap log+permit + deny. Similar to the above, doing the log permit, etc.. is all dependent on the platform and what scale is feasible. Some devices you can?t do things like log-input and capture the ingress MAC that originated the packet as it?s been stripped off before it gets to that part of the engine. Similar to Randys previous comments, I would like to see another operator talk about their efforts here that has actually implemented something and is willing to share. Right now, I?ve seen a lot of people say what others should do with ?their? network, and limited data about what they have done to help solve this problem. It?s harder than it seems, and even those that invite regulation and other things, the technology isn?t capable because it?s not something folks ?ask for?. > Probably takes like maybe 50h development work. Let me know how that goes. I?ve found estimates for this stuff can be off by as much as 10x + once all the details are chased down. my wife has regularly been very patient with me when i say ?10 minutes? and it?s closer to 2+ hours. I know we can do better than what the state is today, but there?s only so much that one network can do. - Jared From eric.sieg at gmail.com Wed Feb 5 17:48:59 2014 From: eric.sieg at gmail.com (Eric Sieg) Date: Wed, 5 Feb 2014 12:48:59 -0500 Subject: Looking for Time Warner NOC contact Message-ID: Need some assistance isolating a connectivity issue between their customer and mine. Any assistance/direction would be greatly appreciated as normal paths have been exhausted. From jra at baylink.com Wed Feb 5 17:55:30 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 05 Feb 2014 12:55:30 -0500 Subject: Done a physical security audit lately? Message-ID: <28548c36-cbce-49fa-ba70-d465dc2bcb40@email.android.com> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack-on-calif-power-station-raises-terrorism-fears -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From saku at ytti.fi Wed Feb 5 18:01:09 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 5 Feb 2014 20:01:09 +0200 Subject: BCP38 is hard, was TWC (AS11351) blocking all NTP? In-Reply-To: <11FCB9B4-E44D-40C2-9BE4-5045208658D1@puck.nether.net> References: <20140205002905.57856.qmail@joyce.lan> <20140205083507.GA20473@pob.ytti.fi> <11FCB9B4-E44D-40C2-9BE4-5045208658D1@puck.nether.net> Message-ID: <20140205180109.GA2330@pob.ytti.fi> On (2014-02-05 11:15 -0500), Jared Mauch wrote: > The problem is many of these can compile to larger than the physical amount of space in the router/LC have to handle it. I?ve done presentations to vendors about what percentage (in bytes and per-line) of the configuration is of what component. 90%+ tends to be customer-specific prefix-list/set/filter lines. Absolutely. But the good thing is, we don't need to have it comprehensively deployed in transit scenarios, just as long as spoofing domains are sufficiently fragmented DoS attack gets get better pay off from not spoofing. -- ++ytti From Jason_Livingood at cable.comcast.com Wed Feb 5 18:06:59 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 5 Feb 2014 18:06:59 +0000 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <005001cf2227$2b9c3480$82d49d80$@iname.com> Message-ID: Cool, thanks for the pointed. Now if we could get the data by ASN and publish it on a site like bcp38.info, that would be awesome. On 2/4/14, 11:03 PM, "Frank Bulk" wrote: >Here's such a report: > >http://spoofer.cmand.org/summary.php > >Frank > >-----Original Message----- >From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] >Sent: Tuesday, February 04, 2014 6:53 PM >To: Octavio Alvarez; North American Network Operators' Group >Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] > >On 2/4/14, 7:48 PM, "Octavio Alvarez" wrote: > >>What I'm failing to understand, and again, please excuse me if I'm >>oversimplifying, is what data do you need from researchers, >>specifically. What specific actionable data would be helpful? Why does >>the lack of the data prevent you from applying an ACL. > >What I am suggesting is that the community at large needs measurement >data, rather than individual network operators (which already know if they >do or do not implement BCP38). Only with a long list of operators that DO >prevent spoofing and a list of those that DO NOT, backed up with a decent >data set (enough measurement points, enough measurement tests, across >enough time, with an openly shared methodology), can the community start >to encourage non-adopters to change their position. Just my two cents >though... > >Jason > > > > From christopher.morrow at gmail.com Wed Feb 5 18:20:59 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 5 Feb 2014 13:20:59 -0500 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: References: <005001cf2227$2b9c3480$82d49d80$@iname.com> Message-ID: I here tell the spoofer project people are looking to improve their data and stats... And reporting. On Feb 5, 2014 1:08 PM, "Livingood, Jason" < Jason_Livingood at cable.comcast.com> wrote: > Cool, thanks for the pointed. Now if we could get the data by ASN and > publish it on a site like bcp38.info, that would be awesome. > > > > On 2/4/14, 11:03 PM, "Frank Bulk" wrote: > > >Here's such a report: > > > >http://spoofer.cmand.org/summary.php > > > >Frank > > > >-----Original Message----- > >From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] > >Sent: Tuesday, February 04, 2014 6:53 PM > >To: Octavio Alvarez; North American Network Operators' Group > >Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] > > > >On 2/4/14, 7:48 PM, "Octavio Alvarez" wrote: > > > >>What I'm failing to understand, and again, please excuse me if I'm > >>oversimplifying, is what data do you need from researchers, > >>specifically. What specific actionable data would be helpful? Why does > >>the lack of the data prevent you from applying an ACL. > > > >What I am suggesting is that the community at large needs measurement > >data, rather than individual network operators (which already know if they > >do or do not implement BCP38). Only with a long list of operators that DO > >prevent spoofing and a list of those that DO NOT, backed up with a decent > >data set (enough measurement points, enough measurement tests, across > >enough time, with an openly shared methodology), can the community start > >to encourage non-adopters to change their position. Just my two cents > >though... > > > >Jason > > > > > > > > > > > From jhaas at pfrc.org Wed Feb 5 19:17:27 2014 From: jhaas at pfrc.org (Jeffrey Haas) Date: Wed, 5 Feb 2014 14:17:27 -0500 Subject: [iab-chair@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"] Message-ID: <20140205191727.GN8022@pfrc> It's IETF stuff. Operator sanity check would probably be appreciated. :-) -- Jeff ----- Forwarded message from IAB Chair ----- Date: Wed, 29 Jan 2014 11:16:56 -0500 From: IAB Chair To: IETF Announce Cc: IAB , IETF Subject: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering" This is a call for review of "Technical Considerations for Internet Service Blocking and Filtering" prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ The Call for Review will last until 26 February 2014. Please send comments to iab at iab.org. On behalf of the IAB, Russ Housley IAB Chair ----- End forwarded message ----- From asullivan at dyn.com Wed Feb 5 19:30:15 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 5 Feb 2014 14:30:15 -0500 Subject: [iab-chair@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"] In-Reply-To: <20140205191727.GN8022@pfrc> References: <20140205191727.GN8022@pfrc> Message-ID: <20140205193013.GA20042@dyn.com> On Wed, Feb 05, 2014 at 02:17:27PM -0500, Jeffrey Haas wrote: > It's IETF stuff. Operator sanity check would probably be appreciated. :-) Speaking as a member of the IAB but not for the IAB, I would certainly appreciate that review. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From bill at herrin.us Wed Feb 5 19:57:13 2014 From: bill at herrin.us (William Herrin) Date: Wed, 5 Feb 2014 14:57:13 -0500 Subject: [iab-chair@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"] In-Reply-To: <20140205191727.GN8022@pfrc> References: <20140205191727.GN8022@pfrc> Message-ID: > This is a call for review of "Technical Considerations for Internet > Service Blocking and Filtering" prior to potential approval as an > IAB stream RFC. > > The document is available for inspection here: > https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ > > The Call for Review will last until 26 February 2014. > Please send comments to iab at iab.org. Howdy, Some initial thoughts: I'm not sure about the difference between network blocking and endpoint blocking, but I think differences between the three major types of network blocking are at least as significant as the difference between network blocking and rendezvous blocking. If the document calls out rendezvous blocking, it should call out all three types of network blocking as well. Each has very different characteristics which would be more effectively graded on the document's criteria if discussed separately. The three major types of networking blocking are: packet blocking - only packets meeting certain criteria are allowed, (e.g. IP destination address 10.0.0.1, inbound TCP with the ACK flag set) stateful connection blocking - only packets belonging to layer-4 connections meeting certain criteria are allowed (e.g. TCP initiated to port 80 outbound, TCP initiated to port 443 outbound) protocol blocking - only connections containing specific known protocols (e.g. http, ssl) are allowed, or alternately specific identifiable protocols are blacklisted The latter is a relatively new (within the last half decade) thing that has become widely implemented in large enterprises. It started out as deep packet inspection but has become much more. Also, section 4.1.3 treats asymmetric routing as if it was usually or always outside the control of the blocking entity. That's not reasonable. There are as many network blocking scenarios where the blocking authority can enforce symmetric routing as there are scenarios where it can't. The efficacy discussion should recognize that you have those two groups of scenarios and that the efficacy of network blocking varies in each. Further, the user's ability to tunnel around such blocks depends heavily on the type of network blocking. Packet blocking can generally be tunneled around given cooperating endpoints. When protocol blocking is active, that proves far more challenging. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Wed Feb 5 20:08:07 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Feb 2014 15:08:07 -0500 Subject: Done a physical security audit lately? In-Reply-To: <28548c36-cbce-49fa-ba70-d465dc2bcb40@email.android.com> References: <28548c36-cbce-49fa-ba70-d465dc2bcb40@email.android.com> Message-ID: hard to do physical security protections on a 1.5mile radius around your assets, eh? reference: also, see vijay's presentation: (slide 12) -chris (point about general physical security reviews not withstanding) On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth wrote: > http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack-on-calif-power-station-raises-terrorism-fears > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From Marla.Azinger at FTR.com Wed Feb 5 20:24:36 2014 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Wed, 5 Feb 2014 20:24:36 +0000 Subject: Done a physical security audit lately? In-Reply-To: References: <28548c36-cbce-49fa-ba70-d465dc2bcb40@email.android.com> Message-ID: http://www.youtube.com/watch?v=NOZM5ZwN0kM nope not a problem -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Wednesday, February 05, 2014 12:08 PM To: Jay Ashworth Cc: nanog list Subject: Re: Done a physical security audit lately? hard to do physical security protections on a 1.5mile radius around your assets, eh? reference: also, see vijay's presentation: (slide 12) -chris (point about general physical security reviews not withstanding) On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth wrote: > http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack > -on-calif-power-station-raises-terrorism-fears > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From morrowc.lists at gmail.com Wed Feb 5 20:33:39 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Feb 2014 15:33:39 -0500 Subject: Done a physical security audit lately? In-Reply-To: References: <28548c36-cbce-49fa-ba70-d465dc2bcb40@email.android.com> Message-ID: On Wed, Feb 5, 2014 at 3:24 PM, Azinger, Marla wrote: > http://www.youtube.com/watch?v=NOZM5ZwN0kM > > nope not a problem wait, wait, wait... check out the video at :54 is that an f'ing unicorn?? I think it is! > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Wednesday, February 05, 2014 12:08 PM > To: Jay Ashworth > Cc: nanog list > Subject: Re: Done a physical security audit lately? > > hard to do physical security protections on a 1.5mile radius around your assets, eh? > reference: > > also, see vijay's presentation: (slide 12) > > -chris > (point about general physical security reviews not withstanding) > > On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth wrote: >> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack >> -on-calif-power-station-raises-terrorism-fears >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From Marla.Azinger at FTR.com Wed Feb 5 20:38:08 2014 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Wed, 5 Feb 2014 20:38:08 +0000 Subject: Done a physical security audit lately? In-Reply-To: References: <28548c36-cbce-49fa-ba70-d465dc2bcb40@email.android.com> Message-ID: <699a3bfb61844d66872288d46b7af844@BY2PR06MB488.namprd06.prod.outlook.com> Can't get anything past you Chris! :-) Um Yeah! Why wouldn't it be!? -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Wednesday, February 05, 2014 12:34 PM To: Azinger, Marla Cc: Jay Ashworth; nanog list Subject: Re: Done a physical security audit lately? On Wed, Feb 5, 2014 at 3:24 PM, Azinger, Marla wrote: > http://www.youtube.com/watch?v=NOZM5ZwN0kM > > nope not a problem wait, wait, wait... check out the video at :54 is that an f'ing unicorn?? I think it is! > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Wednesday, February 05, 2014 12:08 PM > To: Jay Ashworth > Cc: nanog list > Subject: Re: Done a physical security audit lately? > > hard to do physical security protections on a 1.5mile radius around your assets, eh? > reference: > > also, see vijay's presentation: (slide 12) > te.pdf> > > -chris > (point about general physical security reviews not withstanding) > > On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth wrote: >> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attac >> k -on-calif-power-station-raises-terrorism-fears >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From mstaudinger at corp.earthlink.com Wed Feb 5 20:59:25 2014 From: mstaudinger at corp.earthlink.com (Staudinger, Malcolm) Date: Wed, 5 Feb 2014 20:59:25 +0000 Subject: Verizon Wireless NOC contact Message-ID: Can someone from Verizon contact me off-list? We're seeing DNS resolution issues to Earthlink domains from Verizon Wireless customers, and have only gotten the run around from our "usual" Verizon NOC contacts Malcolm Staudinger Information Security Analyst | EIS EarthLink www.earthlink.net E: mstaudinger at corp.earthlink.com From nick at foobar.org Wed Feb 5 21:23:32 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 05 Feb 2014 21:23:32 +0000 Subject: [iab-chair@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"] In-Reply-To: <20140205191727.GN8022@pfrc> References: <20140205191727.GN8022@pfrc> Message-ID: <52F2ABD4.5050306@foobar.org> On 05/02/2014 19:17, Jeffrey Haas wrote: > It's IETF stuff. Operator sanity check would probably be appreciated. :-) Jeff, maybe run this past grow at ietf? Nick > ----- Forwarded message from IAB Chair ----- > > Date: Wed, 29 Jan 2014 11:16:56 -0500 > From: IAB Chair > To: IETF Announce > Cc: IAB , IETF > Subject: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering" > > This is a call for review of "Technical Considerations for Internet > Service Blocking and Filtering" prior to potential approval as an > IAB stream RFC. > > The document is available for inspection here: > https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ > > The Call for Review will last until 26 February 2014. > Please send comments to iab at iab.org. > > On behalf of the IAB, > Russ Housley > IAB Chair > > ----- End forwarded message ----- > From jra at baylink.com Wed Feb 5 21:24:42 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Feb 2014 16:24:42 -0500 (EST) Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <52F18A5E.8050803@alvarezp.ods.org> Message-ID: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Octavio Alvarez" > Maybe I'm oversimplifying things but I'm really curious to know why > can't the nearest-to-end-user ACL-enabled router simply have an ACL to > only allows packets from end-users that has a valid source-address > from the network segment they provide service to. The common answer, Octavio, at least *used to* be "our line cards aren't smart enough to implement strict-unicast-RPF, and our boxes don't have enough horsepower to handle every packet through the CPU". As I've noted, I'm not sure I believe that's true of current generation gear, and if it *is*, then it should cost manufacturers business. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Wed Feb 5 21:33:50 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Feb 2014 16:33:50 -0500 (EST) Subject: POLL: BCP38 Name And Shame In-Reply-To: <16144.1391572892@turing-police.cc.vt.edu> Message-ID: <8185587.7298.1391636030833.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > Time to name-and-shame. It's 2014. Who's still shipping gear that > can't manage eyeball-facing BCP38? It sure is. ==== POLL: If you run "eyeball" equipment -- edge concentrators/routers/CMTSen, would you please post, without employer attribution, what make & model it is, and which firmware rev it's running, and whether it has a knob for unicast-strict-RPF or an equivalent automatic filtering method which is compatible with "flip the switch" BCP38 deployment, and preferably runs on the relevant line cards, not CPU. At your option, you can mention whether it's already on, whether you had to look it up, and which network it is. :-) PLEASE RESPOND to jra+bcp38 at baylink.com, not the list; I will aggregate. I do not plan to mention any people in the results, but if I'm told the names of networks in sufficient specificity to avoid confusion, I will include those. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Wed Feb 5 21:40:47 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Feb 2014 16:40:47 -0500 (EST) Subject: BCP38 In-Reply-To: <1757991.7300.1391636435616.JavaMail.root@benjamin.baylink.com> Message-ID: <21249029.7302.1391636447550.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Frank Bulk" > Here's such a report: > > http://spoofer.cmand.org/summary.php And those results aren't bad; they amount to between 2/3 and 3/4 of real source address space already having something implemented, if I'm reading them correctly. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From joelja at bogus.com Wed Feb 5 21:43:13 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 05 Feb 2014 13:43:13 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> References: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> Message-ID: <52F2B071.90209@bogus.com> On 2/5/14, 1:24 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Octavio Alvarez" > >> Maybe I'm oversimplifying things but I'm really curious to know why >> can't the nearest-to-end-user ACL-enabled router simply have an ACL to >> only allows packets from end-users that has a valid source-address >> from the network segment they provide service to. > > The common answer, Octavio, at least *used to* be "our line cards aren't > smart enough to implement strict-unicast-RPF, and our boxes don't have > enough horsepower to handle every packet through the CPU". > > As I've noted, I'm not sure I believe that's true of current generation > gear, and if it *is*, then it should cost manufacturers business. There are boxes that haven't aged out of the network yet where that's an issue, some are more datacenter-centric than others. force10 e1200 was one platform that had this limitation for example. > Cheers, > -- jra > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From jimmy.changa007 at gmail.com Wed Feb 5 21:45:29 2014 From: jimmy.changa007 at gmail.com (Joe Marr) Date: Wed, 5 Feb 2014 16:45:29 -0500 Subject: Comcast NOC contact Message-ID: I'm seeing an odd routing issue with Comcast and would like their help. Does any have any contact information for them? From jra at baylink.com Wed Feb 5 21:46:04 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 5 Feb 2014 16:46:04 -0500 (EST) Subject: BCP38 is hard; let's go shopping! In-Reply-To: <52F2B071.90209@bogus.com> Message-ID: <7852910.7306.1391636764901.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "joel jaeggli" > > As I've noted, I'm not sure I believe that's true of current generation > > gear, and if it *is*, then it should cost manufacturers business. > > There are boxes that haven't aged out of the network yet where that's an > issue, some are more datacenter-centric than others. force10 e1200 was > one platform that had this limitation for example. So making sure manufacturers are producing gear that's BCP38-compliant, and buyers have it on their tick-list, is still a productive goal, too. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jneiberger at gmail.com Wed Feb 5 21:56:01 2014 From: jneiberger at gmail.com (John Neiberger) Date: Wed, 5 Feb 2014 14:56:01 -0700 Subject: Comcast NOC contact In-Reply-To: References: Message-ID: Sure. Send me the details and I'll take a look or reach out to another more appropriate team. Thanks, John On Wed, Feb 5, 2014 at 2:45 PM, Joe Marr wrote: > I'm seeing an odd routing issue with Comcast and would like their help. > Does any have any contact information for them? > From joelja at bogus.com Wed Feb 5 22:02:30 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 05 Feb 2014 14:02:30 -0800 Subject: BCP38 is hard; let's go shopping! In-Reply-To: <7852910.7306.1391636764901.JavaMail.root@benjamin.baylink.com> References: <7852910.7306.1391636764901.JavaMail.root@benjamin.baylink.com> Message-ID: <52F2B4F6.7030909@bogus.com> On 2/5/14, 1:46 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "joel jaeggli" > >>> As I've noted, I'm not sure I believe that's true of current generation >>> gear, and if it *is*, then it should cost manufacturers business. >> >> There are boxes that haven't aged out of the network yet where that's an >> issue, some are more datacenter-centric than others. force10 e1200 was >> one platform that had this limitation for example. > > So making sure manufacturers are producing gear that's BCP38-compliant, > and buyers have it on their tick-list, is still a productive goal, too. it is... The products are probably close to the end of their sales life, but they'll likely be around for a while. > Cheers, > -- jra > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Wed Feb 5 22:21:42 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Feb 2014 17:21:42 -0500 Subject: BCP38 is hard; let's go shopping! In-Reply-To: <7852910.7306.1391636764901.JavaMail.root@benjamin.baylink.com> References: <52F2B071.90209@bogus.com> <7852910.7306.1391636764901.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 5, 2014 at 4:46 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "joel jaeggli" > >> > As I've noted, I'm not sure I believe that's true of current generation >> > gear, and if it *is*, then it should cost manufacturers business. >> >> There are boxes that haven't aged out of the network yet where that's an >> issue, some are more datacenter-centric than others. force10 e1200 was >> one platform that had this limitation for example. > > So making sure manufacturers are producing gear that's BCP38-compliant, > and buyers have it on their tick-list, is still a productive goal, too. but, if it's a datacenter deployment there are mitigations you can perform aside from uRPF... right? you COULD just use a simple acl on the interface: "my local network is..." which you could even automate. you COULD do dhcp-snooping/mac-locking/etc and ensure that the end-host is only using the one address(es) it's permitted to use. (potentially harder to do on some gear) you COULD clamp the outbound path from edge-L3 box -> code with the right acl, since you konw what traffic should come out of the local L3 edge piece. the answer doesn't' have to be uRPF. From marka at isc.org Thu Feb 6 00:11:43 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Feb 2014 11:11:43 +1100 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: Your message of "Wed, 05 Feb 2014 09:06:18 -0800." References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> Message-ID: <20140206001143.8FA17E78FE4@rock.dv.isc.org> In message , Landon Stewart writes: > --f46d042c63a5ad12dd04f1abc724 > Content-Type: text/plain; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > On 4 February 2014 17:18, Mark Andrews wrote: > > > > That would never fly, because it would put the politicians at odds with > > > the telecom buddies that make huge political donations. Hard to throw > > > someone in jail then hit them up for campaign money. What will > > > probably happen is the same thing we do with everything else that might > > > be used for evil purposes but where we don't want to tackle the real > > > underlying problem -- just write a law banning something and hope the > > > problem goes away. > > > > No, you write a law requiring something, e.g. BCP 38 filtering by > > ISPs, and you audit it. You also make the ISPs directors liable > > for the impact that results from spoofed traffic from them. > > > > Making it law puts all the ISP's in the country on a equal footing > > with respect to implementation costs. > > > > This is a slippery slope if I've ever seen one. If we start having > legislators making laws for how packets are served we are just begging for > them to put their feet into all kinds of doors that we don't want them in. Well when industries don't self regulate governments step in. This industry is demonstratably incapble of regulating itself in this area despite lots of evidence of the problems being caused for lots of years. This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 years. Everybody else is having to deal the problems caused by these bad actors. Hell, I suspect you could send the directors to gaol or make them pay a heavy fine today by properly examining the existing laws. A new law would just make the problem more explicit. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sethm at rollernet.us Thu Feb 6 00:34:59 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 05 Feb 2014 16:34:59 -0800 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> References: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> Message-ID: <52F2D8B3.6010903@rollernet.us> On 2/5/14, 13:24, Jay Ashworth wrote: > The common answer, Octavio, at least*used to* be "our line cards aren't > smart enough to implement strict-unicast-RPF, and our boxes don't have > enough horsepower to handle every packet through the CPU". > > As I've noted, I'm not sure I believe that's true of current generation > gear, and if it*is*, then it should cost manufacturers business. In Cisco 6500 land - which were very popular - Earl7 uRPF is limited to one of strict or loose (no mixing modes) for IPv4 only. Otherwise you have to rely on ACLs and the possibility of running out of TCAM space for them depending on density. The Sup2T (Earl8) does fix these limitations: uRPF is configurable per-interface basis and independent of IPv4/IPv6, and can be a mix of loose or strict mode. But Sup2T only came out in 2011. ~Seth From randy at psg.com Thu Feb 6 02:40:34 2014 From: randy at psg.com (Randy Bush) Date: Thu, 06 Feb 2014 11:40:34 +0900 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140206001143.8FA17E78FE4@rock.dv.isc.org> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <20140206001143.8FA17E78FE4@rock.dv.isc.org> Message-ID: > Well when industries don't self regulate governments step in. This > industry is demonstratably incapble of regulating itself in this > area despite lots of evidence of the problems being caused for lots > of years. This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 > years. Everybody else is having to deal the problems caused by > these bad actors. > > Hell, I suspect you could send the directors to gaol or make them > pay a heavy fine today by properly examining the existing laws. A new > law would just make the problem more explicit. and the reason for the extreme hyperbole is that this problem is seriously affecting the service provider where you work? From mysidia at gmail.com Thu Feb 6 03:06:28 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Feb 2014 21:06:28 -0600 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140205084657.GA22744@pob.ytti.fi> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> Message-ID: On Wed, Feb 5, 2014 at 2:46 AM, Saku Ytti wrote: > > If we keep thinking this problem as last-mile port problem, it won't be > solved in next 20 years. Because lot of those ports really can't do RPF and even > if [snip] The last-mile ports don't necessarily need RPF; a simple inbound access list on the ISP side....... Or even outbound on CPE side, with all valid source addresses allowed, and nothing else: is just perfect. In essence; it is a last-mile problem, and that is part of the challenge. The last-mile is the best possible place to filter, without breaking things. As for the idea, that the world can take a shortcut, and filter in some manner at transit services is tantalizing, but also: is not quite adequate, and that's probably not going to happen either. > [snip] > However transit border doing ACL is something that seems to very > controversial, there is no universal consensus that it even should be Anything that is likely to blackhole legitimate traffic is going to be controversial. IP source based filtering on transit links may very well fall into that category of greatly increasing that risk in many cases. Restricting the source IP address range in from transit links is a bad idea, unless you can be certain that no other source IPs will show up legitimately, which you cannot necessarily be. If i am a transit provider, and I connect with a peer network buying transit from me, then they get to route traffic over that link: according to the routes my network announced to their router. If my router discards any of that traffic based on source, then the route I propagated to my peer was dishonest --- that is, it would mean my route announcement was a lie: the filtering would in essence make some routes blackhole routes, and I am disrupting the connectivity for the unexpected source addresses, just by turning up that link. Or I am at risk of disrupting connectivity in the future, to any network that my downstream peer later interconnects with, if they will also provide transit in that relationship, and also... it would be a common practice on many networks to turn up such interconnections at a date before I or any other transit upstreams are informed. It is likely from time to time, that many transit downstreams will obtain additional address allocations, or that they will make additional network connections: especially, if in fact, my downstream peer is multihomed, possibly with numerous providers, and they may themselves be a transit provider. At a certain level; "RPF" does not work, because: by design, routing IN and OUT can very well be asymmetric traffic flows for networks that are multihomed. Not announcing the source to a specific network, doesn't make it OKAY for the adjacent transit network to drop traffic from that source. > done and > quite few seem to do it. I feel we need to change this, and make community > at > large agree it is the BCP and solve the challenges presented. > -- -JH From fergdawgster at mykolab.com Thu Feb 6 03:20:56 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 05 Feb 2014 19:20:56 -0800 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> Message-ID: <52F2FF98.2030507@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/5/2014 7:06 PM, Jimmy Hess wrote: > The last-mile is the best possible place to filter, without > breaking things. I could not agree more. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLy/5gACgkQKJasdVTchbKXbAEAqFswL2qtqIgRcALVMLdQA0H/ dRLvmDhCoXEmRtOB2B8BAMbH489q8lB/qdiEofYviAAnNA6aqpT38ASXDzBUKO/K =xjIk -----END PGP SIGNATURE----- From marka at isc.org Thu Feb 6 03:35:37 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Feb 2014 14:35:37 +1100 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: Your message of "Wed, 05 Feb 2014 19:20:56 -0800." <52F2FF98.2030507@mykolab.com> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> <52F2FF98.2030507@mykolab.com> Message-ID: <20140206033537.9A454E7FF56@rock.dv.isc.org> In message <52F2FF98.2030507 at mykolab.com>, Paul Ferguson writes: > On 2/5/2014 7:06 PM, Jimmy Hess wrote: > > > The last-mile is the best possible place to filter, without > > breaking things. > > I could not agree more. :-) > > - - ferg Remember "last mile" includes "datacenter" and "noc". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fergdawgster at mykolab.com Thu Feb 6 03:41:03 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 05 Feb 2014 19:41:03 -0800 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140206033537.9A454E7FF56@rock.dv.isc.org> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> <52F2FF98.2030507@mykolab.com> <20140206033537.9A454E7FF56@rock.dv.isc.org> Message-ID: <52F3044F.5050803@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/5/2014 7:35 PM, Mark Andrews wrote: > In message <52F2FF98.2030507 at mykolab.com>, Paul Ferguson writes: >> On 2/5/2014 7:06 PM, Jimmy Hess wrote: >> >>> The last-mile is the best possible place to filter, without >>> breaking things. >> >> I could not agree more. :-) >> >> - - ferg > > Remember "last mile" includes "datacenter" and "noc". > Whatever gets it done. I'm just sick of hearing why people can't do it, instead of reasons why they can. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLzBE8ACgkQKJasdVTchbL6mQEAo6p/QQxyEdiQkf1/91nteK1u z3zyR9QbO7dtDuEBftkBANAlfy+zqbMuOp03rIiPu/pk3Ixt+mo58Yjs3fOHfqUG =9wRN -----END PGP SIGNATURE----- From randy at psg.com Thu Feb 6 03:43:12 2014 From: randy at psg.com (Randy Bush) Date: Thu, 06 Feb 2014 12:43:12 +0900 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <52F2FF98.2030507@mykolab.com> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> <52F2FF98.2030507@mykolab.com> Message-ID: >> The last-mile is the best possible place to filter, without breaking >> things. > I could not agree more. :-) very large consumer populations are on metro-ether-like things. and it gets kinkier from there, don't eat before looking at what ntt-east has done with ngn. i fear we really have most of the easy big deployments and all of the cool kids. we're down to statistically small stubborn do-nothings and some folk with equipment that will take years to be pushed off net. randy From fergdawgster at mykolab.com Thu Feb 6 03:48:24 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 05 Feb 2014 19:48:24 -0800 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> <52F2FF98.2030507@mykolab.com> Message-ID: <52F30608.8000704@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/5/2014 7:43 PM, Randy Bush wrote: >>> The last-mile is the best possible place to filter, without >>> breaking things. >> I could not agree more. :-) > > very large consumer populations are on metro-ether-like things. > and it gets kinkier from there, don't eat before looking at what > ntt-east has done with ngn. > > i fear we really have most of the easy big deployments and all of > the cool kids. we're down to statistically small stubborn > do-nothings and some folk with equipment that will take years to be > pushed off net. > Maybe. Maybe not. I think it really depends how we approach the problem -- apparently our approaches up until now have been failures to a certain degree. At least 20-30% failure, if you believe the Spoofer Project numbers. I'd like to think (and I am not happy smiley person as you well know) that perhaps we can motivate some younger, brighter, ingenious people who have not been tilting at this for 15 years to consider new ways to approach this problem. :-) <-- Smiley! - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLzBggACgkQKJasdVTchbL8hwEAwXbejfCFaOQnqYz6v8xcXfb7 uTmSIWZj+kuiGh976lUA/A5gGGrrAzaVyp3SqX57p5AR8w9kfMQEEbVMLCn7il4R =FE9f -----END PGP SIGNATURE----- From randy at psg.com Thu Feb 6 03:55:37 2014 From: randy at psg.com (Randy Bush) Date: Thu, 06 Feb 2014 12:55:37 +0900 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <52F30608.8000704@mykolab.com> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> <52F2FF98.2030507@mykolab.com> <52F30608.8000704@mykolab.com> Message-ID: > I'd like to think (and I am not happy smiley person as you well know) > that perhaps we can motivate some younger, brighter, ingenious people > who have not been tilting at this for 15 years to consider new ways to > approach this problem. :-) <-- Smiley! we should definitely scream at them and threaten legal action and lightning strikes from the gods. randy From mark.tinka at seacom.mu Thu Feb 6 04:32:26 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 06:32:26 +0200 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> References: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> Message-ID: <201402060632.26462.mark.tinka@seacom.mu> On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth wrote: > As I've noted, I'm not sure I believe that's true of > current generation gear, and if it *is*, then it should > cost manufacturers business. But only matters if you're refreshing or just starting out. A lot of operators have a large installed base of such kit, and given horsepower is still plenty, getting that swapped out is a tall ask. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jra at baylink.com Thu Feb 6 04:34:16 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 05 Feb 2014 23:34:16 -0500 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <201402060632.26462.mark.tinka@seacom.mu> References: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> <201402060632.26462.mark.tinka@seacom.mu> Message-ID: <0e554157-b925-4a2a-9c0d-4f751c21302c@email.android.com> Sure. Part of the data collection task. Making sure all the current new gear knows how, still a good idea. On February 5, 2014 11:32:26 PM EST, Mark Tinka wrote: >On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth >wrote: > >> As I've noted, I'm not sure I believe that's true of >> current generation gear, and if it *is*, then it should >> cost manufacturers business. > >But only matters if you're refreshing or just starting out. > >A lot of operators have a large installed base of such kit, >and given horsepower is still plenty, getting that swapped >out is a tall ask. > >Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mark.tinka at seacom.mu Thu Feb 6 04:38:08 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 06:38:08 +0200 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <0e554157-b925-4a2a-9c0d-4f751c21302c@email.android.com> References: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> <201402060632.26462.mark.tinka@seacom.mu> <0e554157-b925-4a2a-9c0d-4f751c21302c@email.android.com> Message-ID: <201402060638.08567.mark.tinka@seacom.mu> On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth wrote: > Sure. Part of the data collection task. Making sure all > the current new gear knows how, still a good idea. Yep - like Joel said; current kit supports it (well, the ones I buy, anyway), and certainly a good idea for operators to make sure their favorite vendor can support this when they run their next purchase cycle. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jra at baylink.com Thu Feb 6 04:39:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 05 Feb 2014 23:39:56 -0500 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <201402060638.08567.mark.tinka@seacom.mu> References: <5822441.7294.1391635482579.JavaMail.root@benjamin.baylink.com> <201402060632.26462.mark.tinka@seacom.mu> <0e554157-b925-4a2a-9c0d-4f751c21302c@email.android.com> <201402060638.08567.mark.tinka@seacom.mu> Message-ID: I'm going to be somewhat of a pain in everybody's ass this year, pounding on the drum whenever the topic pops up. :-) On February 5, 2014 11:38:08 PM EST, Mark Tinka wrote: >On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth >wrote: > >> Sure. Part of the data collection task. Making sure all >> the current new gear knows how, still a good idea. > >Yep - like Joel said; current kit supports it (well, the >ones I buy, anyway), and certainly a good idea for operators >to make sure their favorite vendor can support this when >they run their next purchase cycle. > >Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jfmezei_nanog at vaxination.ca Thu Feb 6 04:52:51 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 05 Feb 2014 23:52:51 -0500 Subject: SIP on FTTH systems Message-ID: <52F31523.4000602@vaxination.ca> Quick question: I am thinking in a possible wholesale FTTH environment operated by a telco where the end user is connected to ISP-X via PPPoE. ONTs have built-in ATAs that can provide POTS service to a house and do SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through. In a scenario where the data PPPoE connection is done by an external router, what are the options to operate the VoIP service so that - VoIP still uses the special lane on the GPON with QoS - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is not involved in routing such traffic or allocating an IP address ? Is the only option to program the ONT to establish its own PPPoE session to the ISP that carries only SIP traffic (and can such a setup make use of the special "lane" reserved for VoIP traffic ? on the gPON system ?) What other scenarios exist ? In normal incumbent-only FTTH systems, does the OLT provision a special IP to the ATA via DHCP and intercepts that traffic to hand off to a local SIP server and never touches the internet ? In the USA, do CLECs have access to homes served only by FTTH ? If so, how it is accomplisehd ? From frnkblk at iname.com Thu Feb 6 05:07:42 2014 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 5 Feb 2014 23:07:42 -0600 Subject: SIP on FTTH systems In-Reply-To: <52F31523.4000602@vaxination.ca> References: <52F31523.4000602@vaxination.ca> Message-ID: <006801cf22f9$5dd64bc0$1982e340$@iname.com> In our vendor's implementation, the main access shelf hands out IPs to the "ATAs" integrated in the ONTs over a separate VLAN. No PPPoE required. Frank -----Original Message----- From: Jean-Francois Mezei [mailto:jfmezei_nanog at vaxination.ca] Sent: Wednesday, February 05, 2014 10:53 PM To: nanog at nanog.org Subject: SIP on FTTH systems Quick question: I am thinking in a possible wholesale FTTH environment operated by a telco where the end user is connected to ISP-X via PPPoE. ONTs have built-in ATAs that can provide POTS service to a house and do SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through. In a scenario where the data PPPoE connection is done by an external router, what are the options to operate the VoIP service so that - VoIP still uses the special lane on the GPON with QoS - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is not involved in routing such traffic or allocating an IP address ? Is the only option to program the ONT to establish its own PPPoE session to the ISP that carries only SIP traffic (and can such a setup make use of the special "lane" reserved for VoIP traffic ? on the gPON system ?) What other scenarios exist ? In normal incumbent-only FTTH systems, does the OLT provision a special IP to the ATA via DHCP and intercepts that traffic to hand off to a local SIP server and never touches the internet ? In the USA, do CLECs have access to homes served only by FTTH ? If so, how it is accomplisehd ? From jfmezei_nanog at vaxination.ca Thu Feb 6 05:13:22 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 06 Feb 2014 00:13:22 -0500 Subject: SIP on FTTH systems In-Reply-To: <006801cf22f9$5dd64bc0$1982e340$@iname.com> References: <52F31523.4000602@vaxination.ca> <006801cf22f9$5dd64bc0$1982e340$@iname.com> Message-ID: <52F319F2.8020700@vaxination.ca> On 14-02-06 00:07, Frank Bulk wrote: > In our vendor's implementation, the main access shelf hands out IPs to the > "ATAs" integrated in the ONTs over a separate VLAN. No PPPoE required. Thanks. This would imply that in a wholesale environment, use of the integrated ATA would have to be charged separatly with the telco then handing off SIP traffic from the OLT to (likely) a nearby CLEC SIP server that is colocated (or pay for transit to internet to reach distant SIP server) I know that in the australian NBN plan, they do charge separatly to access the "dedicated" VoIP service, but this is meant more as a means to access the QoS managed bandwidth than to deal with handoff and IP management service that is performed locally instead of by the ISP. From mansaxel at besserwisser.org Thu Feb 6 07:19:59 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 6 Feb 2014 08:19:59 +0100 Subject: SIP on FTTH systems In-Reply-To: <52F31523.4000602@vaxination.ca> References: <52F31523.4000602@vaxination.ca> Message-ID: <20140206071959.GH24602@besserwisser.org> Subject: SIP on FTTH systems Date: Wed, Feb 05, 2014 at 11:52:51PM -0500 Quoting Jean-Francois Mezei (jfmezei_nanog at vaxination.ca): > Quick question: > > I am thinking in a possible wholesale FTTH environment operated by a > telco where the end user is connected to ISP-X via PPPoE. > > ONTs have built-in ATAs that can provide POTS service to a house and do > SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through. > > In a scenario where the data PPPoE connection is done by an external > router, what are the options to operate the VoIP service so that > > - VoIP still uses the special lane on the GPON with QoS > > - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is > not involved in routing such traffic or allocating an IP address ? Or, one could make sure everything has a globally unique IP address and is using reasonably secured communications. The downside is that one then can't defend the existence of those empire-building middleboxes. It is not the telco way, so is of course unthinkable. Like anything beyond WAP was on cell phones a decade ago. Warum soll man es einfach machen, wenn man es so sch?n komplizieren kann? (Why make things simple when you can build them so beautifully complicated?) -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 We are now enjoying total mutual interaction in an imaginary hot tub ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From rdrake at direcpath.com Thu Feb 6 07:56:09 2014 From: rdrake at direcpath.com (Robert Drake) Date: Thu, 6 Feb 2014 02:56:09 -0500 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: References: <005001cf2227$2b9c3480$82d49d80$@iname.com> Message-ID: <52F34019.6020608@direcpath.com> On 2/5/2014 1:20 PM, Christopher Morrow wrote: > I here tell the spoofer project people are looking to improve their data > and stats... And reporting. I know it's not possible due to the limitations of javascript sandboxing, but this really needs to be browser based so it can be like DNSSEC or MX or IPV6 testing. Users (and reddit) can be coerced into clicking a link if it shows a happy green sign when they pass the test. Asking them to download an executable is too much for most of them. I'd also love a way as a network administrator that I could audit my own network. Even with all the correct knobs tweaked I occasionally find a site where someone turned up an interface and forgot some template commands, or in the case of gear that doesn't support it there might not be a filter on an upstream device even though there should be. It'd be nice to have a CM profile that would attempt to spoof something to a control server then alert if it works. From mark.tinka at seacom.mu Thu Feb 6 08:01:14 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 10:01:14 +0200 Subject: SIP on FTTH systems In-Reply-To: <20140206071959.GH24602@besserwisser.org> References: <52F31523.4000602@vaxination.ca> <20140206071959.GH24602@besserwisser.org> Message-ID: <201402061001.21028.mark.tinka@seacom.mu> On Thursday, February 06, 2014 09:19:59 AM M?ns Nilsson wrote: > Or, one could make sure everything has a globally unique > IP address and is using reasonably secured > communications. The downside is that one then can't > defend the existence of those empire-building > middleboxes. It is not the telco way, so is of course > unthinkable. Like anything beyond WAP was on cell phones > a decade ago. There are, typically, three topology models for modern FTTH (wireline, really) networks that a service provider could deploy: 1. SVLAN N:1 model 2. CVLAN 1:1 model 3. Hybrid of both The SVLAN (N:1) model is simple; just have a single VLAN for each service (VLAN 10 for Internet/Unicast, VLAN 20 for VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy to scale, but if one is using relatively "dumb" AN's (like GPON's or MSAN's), it can be difficult to control how much bandwidth customers need, and how they can roam between services in the home (given CPE ties services to ports). The CVLAN (1:1) model is good for identifying services and bandwidth requirements on a per-customer basis. The main problem with this model is that Multicast traffic gets treated like Unicast, because each customer has a unique VLAN for themselves, and as such, the upstream PE router ends up having to replicate the same linear video stream as many times as there are customers down the line. The Hybrid model, where CVLAN's are used for all Unicast traffic (Internet, VoIP and VoD, typically), and a single SVLAN is used for all customers to handle Multicast traffic (so-called MVLAN). The challenge here is if you're the type of operator that likes to have a consistent set of address per VLAN, it can become a little tricky if your VoIP service is a walled-garden running on private IP space, given it shares the same VLAN as Internet and VoD which would normally run on public IP space. The N:1 SVLAN model is quite simple and scalable for wholesale FTTH services. There is product from some vendors, now, that is built with FTTH in mind. 1U, dense switches (Active-E) that support (reasonably) proper QoS and bandwidth management controls on customer- and core-facing ports, at Layer 2. So that offers you a lot more capability at the AN, and you can manage bandwidth as close to the customer as possible, unlike typical GPON deployments which may not have these features, leaving you to apply bandwidth policy at the PE router - much too far up the line. These new products can also support split horizons across bridge domains (which GPON's and DSLAM's do today), meaning that customers can use the same SVLAN's, but can only communicate via the upstream router (Layer 3), eliminating risk associated with Layer 2 visibility between customers connected to the same bridge domain. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From cdel at firsthand.net Thu Feb 6 09:56:45 2014 From: cdel at firsthand.net (cdel.firsthand.net) Date: Thu, 6 Feb 2014 09:56:45 +0000 Subject: SIP on FTTH systems In-Reply-To: <201402061001.21028.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <20140206071959.GH24602@besserwisser.org> <201402061001.21028.mark.tinka@seacom.mu> Message-ID: <27852B69-BB16-4266-917D-5F3E5388B5CD@firsthand.net> Time for users to consider splitting L2 services from IP ? Christian de Larrinaga > On 6 Feb 2014, at 08:01, Mark Tinka wrote: > > On Thursday, February 06, 2014 09:19:59 AM M?ns Nilsson > wrote: > >> Or, one could make sure everything has a globally unique >> IP address and is using reasonably secured >> communications. The downside is that one then can't >> defend the existence of those empire-building >> middleboxes. It is not the telco way, so is of course >> unthinkable. Like anything beyond WAP was on cell phones >> a decade ago. > > There are, typically, three topology models for modern FTTH > (wireline, really) networks that a service provider could > deploy: > > 1. SVLAN N:1 model > 2. CVLAN 1:1 model > 3. Hybrid of both > > The SVLAN (N:1) model is simple; just have a single VLAN for > each service (VLAN 10 for Internet/Unicast, VLAN 20 for > VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy > to scale, but if one is using relatively "dumb" AN's (like > GPON's or MSAN's), it can be difficult to control how much > bandwidth customers need, and how they can roam between > services in the home (given CPE ties services to ports). > > The CVLAN (1:1) model is good for identifying services and > bandwidth requirements on a per-customer basis. The main > problem with this model is that Multicast traffic gets > treated like Unicast, because each customer has a unique > VLAN for themselves, and as such, the upstream PE router > ends up having to replicate the same linear video stream as > many times as there are customers down the line. > > The Hybrid model, where CVLAN's are used for all Unicast > traffic (Internet, VoIP and VoD, typically), and a single > SVLAN is used for all customers to handle Multicast traffic > (so-called MVLAN). The challenge here is if you're the type > of operator that likes to have a consistent set of address > per VLAN, it can become a little tricky if your VoIP service > is a walled-garden running on private IP space, given it > shares the same VLAN as Internet and VoD which would > normally run on public IP space. > > The N:1 SVLAN model is quite simple and scalable for > wholesale FTTH services. > > There is product from some vendors, now, that is built with > FTTH in mind. 1U, dense switches (Active-E) that support > (reasonably) proper QoS and bandwidth management controls on > customer- and core-facing ports, at Layer 2. So that offers > you a lot more capability at the AN, and you can manage > bandwidth as close to the customer as possible, unlike > typical GPON deployments which may not have these features, > leaving you to apply bandwidth policy at the PE router - > much too far up the line. > > These new products can also support split horizons across > bridge domains (which GPON's and DSLAM's do today), meaning > that customers can use the same SVLAN's, but can only > communicate via the upstream router (Layer 3), eliminating > risk associated with Layer 2 visibility between customers > connected to the same bridge domain. > > Cheers, > > Mark. From notify.sina at gmail.com Thu Feb 6 10:03:32 2014 From: notify.sina at gmail.com (Notify Me) Date: Thu, 6 Feb 2014 11:03:32 +0100 Subject: Need trusted NTP Sources Message-ID: Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot! From outsider at scarynet.org Thu Feb 6 10:27:55 2014 From: outsider at scarynet.org (Alexander Maassen) Date: Thu, 06 Feb 2014 11:27:55 +0100 Subject: Need trusted NTP Sources Message-ID: www.pool.ntp.org -------- Oorspronkelijk bericht -------- Van: Notify Me Datum: Aan: "nanog at nanog.org list" ,afnog at afnog.org Onderwerp: Need trusted NTP Sources Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot! From nick at foobar.org Thu Feb 6 10:43:42 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 06 Feb 2014 10:43:42 +0000 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: <52F3675E.9080609@foobar.org> On 06/02/2014 10:03, Notify Me wrote: > I'm trying to help a company I work for to pass an audit, and we've > been told we need trusted NTP sources (RedHat doesn't cut it). So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service? My head spins. Get new auditors. Your current ones are stupid. Nick From mark.tinka at seacom.mu Thu Feb 6 10:57:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 12:57:20 +0200 Subject: SIP on FTTH systems In-Reply-To: <27852B69-BB16-4266-917D-5F3E5388B5CD@firsthand.net> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <27852B69-BB16-4266-917D-5F3E5388B5CD@firsthand.net> Message-ID: <201402061257.24193.mark.tinka@seacom.mu> On Thursday, February 06, 2014 11:56:45 AM cdel.firsthand.net wrote: > Time for users to consider splitting L2 services from IP > ? But consumer broadband is all about IP; the Layer 2 is needed to transport that IP, and that's a network problem, not a user one. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From notify.sina at gmail.com Thu Feb 6 11:46:06 2014 From: notify.sina at gmail.com (Notify Me) Date: Thu, 6 Feb 2014 12:46:06 +0100 Subject: Need trusted NTP Sources In-Reply-To: <52F3675E.9080609@foobar.org> References: <52F3675E.9080609@foobar.org> Message-ID: We're a redhat shop, and we use redhat auth which by default uses redhat NTP sources. Sounds odd to me too. They claim this is what PCI DSS demands. On Feb 6, 2014 11:43 AM, "Nick Hilliard" wrote: > On 06/02/2014 10:03, Notify Me wrote: > > I'm trying to help a company I work for to pass an audit, and we've > > been told we need trusted NTP sources (RedHat doesn't cut it). > > So presuming that your company is using RH or Fedora or CentOS something, > the auditors are claiming that Red Hat, Inc is trusted enough to provide a > precompiled based operating system with no feasible means of proving its > reliability, but that they're not trustworthy enough to provide a clock > synchronisation service? > > My head spins. > > Get new auditors. Your current ones are stupid. > > Nick > > From notify.sina at gmail.com Thu Feb 6 11:51:45 2014 From: notify.sina at gmail.com (Notify Me) Date: Thu, 6 Feb 2014 12:51:45 +0100 Subject: Need trusted NTP Sources In-Reply-To: <42E0F0207938744EB3DA31C28FC221CFA35D32BE@LCEXMBX02.cmsad.local> References: <42E0F0207938744EB3DA31C28FC221CFA35D32BE@LCEXMBX02.cmsad.local> Message-ID: According to the auditors, "trusted" means 1. Universities or Research facilities (nuclear/atomic facilities, space research (such as NASA) etc.) 2. Main country internet/telecom providers 3. Government departments 4. Satellites (using GPS module) Which is a bit of a tall order over here. On Thu, Feb 6, 2014 at 11:16 AM, Marc Storck wrote: > You may start by checking who is providing NTP services in Africa via the NTP pool. In Africa there are 27 public servers (http://www.pool.ntp.org/zone/africa). > > But then all depends on your definition of "trusted". > > Regards, > > Marc > ________________________________________ > From: Notify Me [notify.sina at gmail.com] > Sent: Thursday, February 06, 2014 11:03 > To: nanog at nanog.org list; afnog at afnog.org > Subject: Need trusted NTP Sources > > Hi ! > > I'm trying to help a company I work for to pass an audit, and we've > been told we need trusted NTP sources (RedHat doesn't cut it). Being > located in Nigeria, Africa, I'm not very knowledgeable about trusted > sources therein. > > Please can anyone help with sources that wouldn't mind letting us sync > from them? > > Thanks a lot! > From nick at foobar.org Thu Feb 6 12:09:24 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 06 Feb 2014 12:09:24 +0000 Subject: Need trusted NTP Sources In-Reply-To: References: <52F3675E.9080609@foobar.org> Message-ID: <52F37B74.6050906@foobar.org> On 06/02/2014 11:46, Notify Me wrote: > We're a redhat shop, and we use redhat auth which by default uses redhat > NTP sources. Sounds odd to me too. They claim this is what PCI DSS demands. PCI DSS states: > 10.4.3 Time settings are received from industry-accepted time sources. The default RHEL time servers are defined as X.rhel.ntp.org. Many people would consider ntp.org as industry-accepted, and there are several PCI-DSS auditing companies out there who explicitly recommend using pool.ntp.org for this purpose. If that's not good enough, the PCI DSS standards explicitly state in the NTP interpretation section: > More information on NTP can be found at www.ntp.org, including > information about time, time standards, and servers. So, if PCI themselves view ntp.org as being authoritative about NTP I can't see any reason why the time servers they publish wouldn't pass an audit. Nick From aledm at qix.co.uk Thu Feb 6 12:11:49 2014 From: aledm at qix.co.uk (Aled Morris) Date: Thu, 6 Feb 2014 12:11:49 +0000 Subject: Need trusted NTP Sources In-Reply-To: References: <42E0F0207938744EB3DA31C28FC221CFA35D32BE@LCEXMBX02.cmsad.local> Message-ID: GPS time sources are pretty cheap (< US$500) and easy to set up nowadays. You could probably build your own for less that US$100: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html Aled On 6 February 2014 11:51, Notify Me wrote: > According to the auditors, "trusted" means > > 1. Universities or Research facilities (nuclear/atomic facilities, > space research (such as NASA) etc.) > 2. Main country internet/telecom providers > 3. Government departments > 4. Satellites (using GPS module) > > Which is a bit of a tall order over here. > > On Thu, Feb 6, 2014 at 11:16 AM, Marc Storck wrote: > > You may start by checking who is providing NTP services in Africa via > the NTP pool. In Africa there are 27 public servers ( > http://www.pool.ntp.org/zone/africa). > > > > But then all depends on your definition of "trusted". > > > > Regards, > > > > Marc > > ________________________________________ > > From: Notify Me [notify.sina at gmail.com] > > Sent: Thursday, February 06, 2014 11:03 > > To: nanog at nanog.org list; afnog at afnog.org > > Subject: Need trusted NTP Sources > > > > Hi ! > > > > I'm trying to help a company I work for to pass an audit, and we've > > been told we need trusted NTP sources (RedHat doesn't cut it). Being > > located in Nigeria, Africa, I'm not very knowledgeable about trusted > > sources therein. > > > > Please can anyone help with sources that wouldn't mind letting us sync > > from them? > > > > Thanks a lot! > > > > From swmike at swm.pp.se Thu Feb 6 12:15:57 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 13:15:57 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402061001.21028.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <20140206071959.GH24602@besserwisser.org> <201402061001.21028.mark.tinka@seacom.mu> Message-ID: On Thu, 6 Feb 2014, Mark Tinka wrote: > There are, typically, three topology models for modern FTTH > (wireline, really) networks that a service provider could > deploy: > > 1. SVLAN N:1 model > 2. CVLAN 1:1 model > 3. Hybrid of both There are more. There are models where each ISP gets its own customer vlan and L2 equipment do inspection of ARP/ND and does security filtering on L2/L3 using this information. There are also L3 networks where the traffic is source-routed out to the correct ISP, or each ISP gets its own VRF in the equipment and it's VRF a long way out. To the original poster. People using PPPoE for FTTH makes me sad. When someone suggests this, please just say "go back to the drawingboard, redo it right". -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Thu Feb 6 12:21:49 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 14:21:49 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> Message-ID: <201402061421.49565.mark.tinka@seacom.mu> On Thursday, February 06, 2014 02:15:57 PM Mikael Abrahamsson wrote: > There are more. There are models where each ISP gets its > own customer vlan and L2 equipment do inspection of > ARP/ND and does security filtering on L2/L3 using this > information. There are also L3 networks where the > traffic is source-routed out to the correct ISP, or each > ISP gets its own VRF in the equipment and it's VRF a > long way out. Agree. The models I listed are typical to an operator that runs its own infrastructure (including the FTTH last mile), and does not necessarily wholesale out to other operators. I've seen certain countries that have given the incumbents leeway to wholesale at the IP level, which the incumbent likes because they "perceive" more control than if they had to hand-off Layer 2 wholesale. In such cases, VRF's and/or logical routers have been deployed. > To the original poster. People using PPPoE for FTTH makes > me sad. When someone suggests this, please just say "go > back to the drawingboard, redo it right". Agree. DHCP really is the way to go, now. Plus, there is good support for IPv6 with vendors today re: DHCP-based subscriber management. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From swmike at swm.pp.se Thu Feb 6 12:29:40 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 13:29:40 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402061421.49565.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <201402061421.49565.mark.tinka@seacom.mu> Message-ID: On Thu, 6 Feb 2014, Mark Tinka wrote: > The models I listed are typical to an operator that runs its own > infrastructure (including the FTTH last mile), and does not necessarily > wholesale out to other operators. I disagree on that one as well. It might be in some markets, but it's not in all. > I've seen certain countries that have given the incumbents leeway to > wholesale at the IP level, which the incumbent likes because they > "perceive" more control than if they had to hand-off Layer 2 wholesale. > In such cases, VRF's and/or logical routers have been deployed. This wasn't incumbents specifically, but just a different model to achieve the same thing, give end users access to multiple ISPs, multiple "cable TV" vendors, and multiple VOIP providers through a neutral network. > Agree. DHCP really is the way to go, now. Plus, there is good support > for IPv6 with vendors today re: DHCP-based subscriber management. What do you mean by subscriber management? This worked 10 years ago, what problem are you saying has been solved recently? -- Mikael Abrahamsson email: swmike at swm.pp.se From m.hotze at hotze.com Thu Feb 6 12:30:49 2014 From: m.hotze at hotze.com (Martin Hotze) Date: Thu, 6 Feb 2014 12:30:49 +0000 Subject: Need trusted NTP Sources Message-ID: > I'm trying to help a company I work for to pass an audit, and we've > been told we need trusted NTP sources (RedHat doesn't cut it). Being > located in Nigeria, Africa, I'm not very knowledgeable about trusted > sources therein. > > Please can anyone help with sources that wouldn't mind letting us sync > from them? given that you trust the US-government (well, ...) you might use your own stratum 1 server using a Raspberry Pi with GPS. here is a well done how-to: http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/ I still need some spare time to get it running, all parts are here, but within my office location I have a bad GPS signal reception, so I have to do it at home. So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), off from these servers build 2 or more stratum 2 timeservers for redistribution to offload your stratum 1 servers. http://clepsydratime.com/Products/Time-Server-NTS3000 is a cool alternative. They are located in Poland, IIRC. And this box sells for less than 2,000 euros (this price is 2 years old). And it gives you GPS (USA), Glonass (Russia) and DCF77 (land based). One of the best Timeservers are sold by meinberg.de just my 2 euro-cents. #m From aledm at qix.co.uk Thu Feb 6 12:41:03 2014 From: aledm at qix.co.uk (Aled Morris) Date: Thu, 6 Feb 2014 12:41:03 +0000 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: On 6 February 2014 12:30, Martin Hotze wrote: > > I'm trying to help a company I work for to pass an audit, and we've > > been told we need trusted NTP sources (RedHat doesn't cut it). Being > > located in Nigeria, Africa, > [...] > So build your own stratum 1 server (maybe a second one with DCF77 or > whatever you can use for redundancy), > I don't think DCF77 is going to reach Nigeria. Aled From mark.tinka at seacom.mu Thu Feb 6 12:42:39 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 14:42:39 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061421.49565.mark.tinka@seacom.mu> Message-ID: <201402061442.43036.mark.tinka@seacom.mu> On Thursday, February 06, 2014 02:29:40 PM Mikael Abrahamsson wrote: > I disagree on that one as well. It might be in some > markets, but it's not in all. I keep using the word "typical", but not sure if you're missing it. Typical, not limited to, i.e., common, but not the only option. I'm basing this on what I've seen in various countries across a few continents I've worked in. > This wasn't incumbents specifically, but just a different > model to achieve the same thing, give end users access > to multiple ISPs, multiple "cable TV" vendors, and > multiple VOIP providers through a neutral network. Again, just an example I gave, not to say it was the norm. The countries I was referring to is where the incumbents either owned the infrastructure and were reluctant to open it up to competitors, or were awarded national broadband projects to deploy and run the infrastructure but were not specifically governed to how low the OSI Layer they can open up the infrastructure to. In other places, it is a business model, in addition to more traditional ways of unbundling. These tend to be more evolved markets, but again, not limited to. > What do you mean by subscriber management? This worked 10 > years ago, what problem are you saying has been solved > recently? End user authentication and management typically being done via PPPoE because that was the best and most secure way to manage customer connections (for some operators, still is). By DHCP I mean an alternative to PPPoE-based authentication where Option 82 and friends can allow service providers to authenticate customers based on AN port, MAC address, VLAN ID, e.t.c., instead of username/password a la PPPoE. This gets passed as part of initial DHCP transactions. Rethinking your comment (because I thought you meant DHCP as the way to go for subscriber management when you debunked PPPoE) I'm guessing you refer to simply assigning IP addresses to customer interfaces in FTTH scenarios? No? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nick at foobar.org Thu Feb 6 12:53:20 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 06 Feb 2014 12:53:20 +0000 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: <52F385C0.4030407@foobar.org> On 06/02/2014 12:30, Martin Hotze wrote: > here is a well done how-to: > http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/ The OP had a question about standards compliance, not about something that made technical sense and would deliver a superior service. The two things aren't incompatible, but they're not especially closely related either. Nick From notify.sina at gmail.com Thu Feb 6 12:53:32 2014 From: notify.sina at gmail.com (Notify Me) Date: Thu, 6 Feb 2014 13:53:32 +0100 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: Raspberries! Not common currency here either, but let's see! grateful for all the input and responses, this list is amazing as usual. On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris wrote: > On 6 February 2014 12:30, Martin Hotze wrote: > >> > I'm trying to help a company I work for to pass an audit, and we've >> > been told we need trusted NTP sources (RedHat doesn't cut it). Being >> > located in Nigeria, Africa, >> > [...] > >> So build your own stratum 1 server (maybe a second one with DCF77 or >> whatever you can use for redundancy), >> > > I don't think DCF77 is going to reach Nigeria. > > Aled From swmike at swm.pp.se Thu Feb 6 12:58:14 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 13:58:14 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402061442.43036.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061421.49565.mark.tinka@seacom.mu> <201402061442.43036.mark.tinka@seacom.mu> Message-ID: On Thu, 6 Feb 2014, Mark Tinka wrote: > End user authentication and management typically being done via PPPoE > because that was the best and most secure way to manage customer > connections (for some operators, still is). Why do you need to authenticate the customer? Don't your documentation system know the port/subscriber mapping? And why is this secure, instead of being tied to a physical connection the customer can now take the credentials and move? If the credentials are stolen, someone else can impersonate that customer. > By DHCP I mean an alternative to PPPoE-based authentication where Option > 82 and friends can allow service providers to authenticate customers > based on AN port, MAC address, VLAN ID, e.t.c., instead of > username/password a la PPPoE. This gets passed as part of initial DHCP > transactions. This worked 10 years ago, it's nothing recent. > Rethinking your comment (because I thought you meant DHCP as the way to > go for subscriber management when you debunked PPPoE) I'm guessing you > refer to simply assigning IP addresses to customer interfaces in FTTH > scenarios? No? Yes? Since option 82 and friends gives you what port the DHCP request came in on, you now log IP/MAC connected to a port, and since you know to what apartment/house this port is physically connected to, nothing more is needed. -- Mikael Abrahamsson email: swmike at swm.pp.se From j at arpa.com Thu Feb 6 12:58:28 2014 From: j at arpa.com (jamie rishaw) Date: Thu, 6 Feb 2014 06:58:28 -0600 Subject: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?] In-Reply-To: <52EFDE87.2050307@mykolab.com> References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <52EFDE87.2050307@mykolab.com> Message-ID: Don't fight it. It's clear that implementation on a per-packet basis of RFC4824 (datagrams over Semaphore Flag Signaling System) would have prevented this entire situation. Refer to sections 3.3 and 3.4. -j On Mon, Feb 3, 2014 at 12:23 PM, Paul Ferguson wrote: > > > On 2/2/2014 2:17 PM, Cb B wrote: > > > And, i agree bcp38 would help but that was published 14 years ago. > > But what? Are you somehow implying that because BCP38 was > "...published 14 years ago" (RFC2267 was initially published in 1998, > and it was subsequently replaced by RFC2827)? From mark.tinka at seacom.mu Thu Feb 6 13:06:45 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 15:06:45 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061442.43036.mark.tinka@seacom.mu> Message-ID: <201402061506.48755.mark.tinka@seacom.mu> On Thursday, February 06, 2014 02:58:14 PM Mikael Abrahamsson wrote: > Why do you need to authenticate the customer? Don't your > documentation system know the port/subscriber mapping? > And why is this secure, instead of being tied to a > physical connection the customer can now take the > credentials and move? If the credentials are stolen, > someone else can impersonate that customer. Which is why I said DHCP was better than PPPoE. Failing to see where we disagree. > This worked 10 years ago, it's nothing recent. In my previous post, I didn't say it was recent. I said it was better than PPPoE if you're deploying FTTH now. What I said was recent was that DHCP_IA and DHCP_IA_PD implementation has improved significantly both in BNG's as well as CPE. Again, failing to see where we disagree. > Yes? Since option 82 and friends gives you what port the > DHCP request came in on, you now log IP/MAC connected to > a port, and since you know to what apartment/house this > port is physically connected to, nothing more is needed. Again, don't see where we disagree. This is a good thing. Some operators provide services with no subscriber management (i.e., no PPPoE, no DHCP; just a static IP address documented about where it is, what street, what building, what floor, what apartment, what customer), while other service providers have a subscriber management technique, PPPoE or DHCP, to log all the same information in concert with the backend. I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH deployments today, and I'm not sure you entirely disagree. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From swmike at swm.pp.se Thu Feb 6 13:46:54 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 14:46:54 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402061506.48755.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061442.43036.mark.tinka@seacom.mu> <201402061506.48755.mark.tinka@seacom.mu> Message-ID: On Thu, 6 Feb 2014, Mark Tinka wrote: > I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH > deployments today, and I'm not sure you entirely disagree. We're in violent agreement it seems. My only beef was that it seemed like you were implying this was something new. -- Mikael Abrahamsson email: swmike at swm.pp.se From anders at abundo.se Thu Feb 6 13:51:51 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Thu, 06 Feb 2014 14:51:51 +0100 Subject: SIP on FTTH systems In-Reply-To: <201402061001.21028.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <20140206071959.GH24602@besserwisser.org> <201402061001.21028.mark.tinka@seacom.mu> Message-ID: <52F39377.4020902@abundo.se> On 2014-02-06 09:01, Mark Tinka wrote: > 1. SVLAN N:1 model > > The SVLAN (N:1) model is simple; just have a single VLAN for > each service (VLAN 10 for Internet/Unicast, VLAN 20 for > VoIP, VLAN 30 for IPTv/Multicast). This is a deep hole, and basically does not work with IPv6. You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection, RA guard and more. One VLAN per customer and a separate multicast is much simpler. Or do something bold, run L3 at the edge :) /Anders From mark.tinka at seacom.mu Thu Feb 6 13:58:11 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 15:58:11 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061506.48755.mark.tinka@seacom.mu> Message-ID: <201402061558.12165.mark.tinka@seacom.mu> On Thursday, February 06, 2014 03:46:54 PM Mikael Abrahamsson wrote: > We're in violent agreement it seems. Tend to agree. > My only beef was > that it seemed like you were implying this was something > new. In most of my travels, there is a healthy amount of resistance toward DHCP from new (but mostly, existing) broadband service providers when choosing between DHCP and PPPoE for Unicast traffic. And the reasons for this vary - we saw the OP is PPPoE-biased, for example. It is better in 2014 than it was in 2011 in those places, but by and large, DHCP adoption for subscriber management is not moving as quickly as one would think, especially when you consider all the FTTH work going on around the world. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Feb 6 14:08:48 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 16:08:48 +0200 Subject: SIP on FTTH systems In-Reply-To: <52F39377.4020902@abundo.se> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> Message-ID: <201402061608.52822.mark.tinka@seacom.mu> On Thursday, February 06, 2014 03:51:51 PM Anders L?winger wrote: > This is a deep hole, and basically does not work with > IPv6. > > You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 > inspection, RA guard and more. One VLAN per customer and > a separate multicast is much simpler. If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. I've also know Huawei OLT's support these split horizons too. > Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From swmike at swm.pp.se Thu Feb 6 14:17:42 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 15:17:42 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402061608.52822.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> <201402061608.52822.mark.tinka@seacom.mu> Message-ID: On Thu, 6 Feb 2014, Mark Tinka wrote: >> Or do something bold, run L3 at the edge :) > > BNG's are too big to distributed that deeply, even in > distributed BNG designs. This would get costly. You don't need a BNG. You need an L3 switch as the first hop the customer is talking to. > Cheap switches that have decent IP/MPLS support are mostly geared toward > Metro-E deployments, i.e., business-grade services. So they are quite > poor with regard to susbcriber management features and capabilities. If you have L3-in-vlan-per-customer at the first hop then you don't really need all of that. If you include rudimentary VRF support then you can even support wholesale. /64 per customer, DHCPv6(-PD) server support in the L3 switch and you're good to go. There is equipment that already claim to do this (I never got to test their implementation based on my requirements because I switched jobs, but they claimed to have implemented everything last year). -- Mikael Abrahamsson email: swmike at swm.pp.se From j at arpa.com Thu Feb 6 14:28:47 2014 From: j at arpa.com (jamie rishaw) Date: Thu, 6 Feb 2014 08:28:47 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: PCI DSS only requires that all clocks be synchronized; It doesn't /require/ "how". If you have servers getting time from external sources (authenticated always a plus) and peering with each other internally, then you comply with PCI DSS 2.0 (3.0 has no changes to this that I'm aware of). OTOH, I'm surprised nobody has mentioned http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html -j On Thu, Feb 6, 2014 at 6:53 AM, Notify Me wrote: > Raspberries! Not common currency here either, but let's see! > grateful for all the input and responses, this list is amazing as usual. > > On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris wrote: >> On 6 February 2014 12:30, Martin Hotze wrote: >> >>> > I'm trying to help a company I work for to pass an audit, and we've >>> > been told we need trusted NTP sources (RedHat doesn't cut it). Being >>> > located in Nigeria, Africa, >>> >> [...] >> >>> So build your own stratum 1 server (maybe a second one with DCF77 or >>> whatever you can use for redundancy), >>> >> >> I don't think DCF77 is going to reach Nigeria. >> >> Aled > -- jamie rishaw // .com.arpa at j <- reverse it. ish. "Reality defeats prejudice." - Rep. Barney Frank From cma at cmadams.net Thu Feb 6 14:35:03 2014 From: cma at cmadams.net (Chris Adams) Date: Thu, 6 Feb 2014 08:35:03 -0600 Subject: Need trusted NTP Sources In-Reply-To: <52F3675E.9080609@foobar.org> References: <52F3675E.9080609@foobar.org> Message-ID: <20140206143503.GB29896@cmadams.net> Once upon a time, Nick Hilliard said: > So presuming that your company is using RH or Fedora or CentOS something, > the auditors are claiming that Red Hat, Inc is trusted enough to provide a > precompiled based operating system with no feasible means of proving its > reliability, but that they're not trustworthy enough to provide a clock > synchronisation service? Red Hat does not provide an NTP service themselves. The default NTP config on a Red Hat Enterprise Linux system uses rhel.pool.ntp.org. I suppose some auditor could dislike the "openness" of pool.ntp.org (basically anybody can join). If that is the case, your best bet is to do some combination of the following: - As others have suggested, set up your own stratum-1 clock (can be done for around $100). Ideally you'd set up more than one. - Set up several servers with a static set of NTP servers rather than the general pool servers. See the lists on www.pool.ntp.org; look under the docs for setting up a server to join the pool. You don't have to actually join the pool, but following those docs is a good way to set up a stable server. After that, point the rest of your servers at your "master" servers, rather than the public pool. -- Chris Adams From mark.tinka at seacom.mu Thu Feb 6 14:42:46 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 16:42:46 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061608.52822.mark.tinka@seacom.mu> Message-ID: <201402061642.49646.mark.tinka@seacom.mu> On Thursday, February 06, 2014 04:17:42 PM Mikael Abrahamsson wrote: > You don't need a BNG. You need an L3 switch as the first > hop the customer is talking to. Fine for FTTB, but not for FTTH where you're serving tens- to-hundreds-of-thousands of customers. If your FTTH deployments are low scale (measure of low or large scale depends on each operator's point of view), the case for doing without subscriber management technologies can be made. > If you have L3-in-vlan-per-customer at the first hop then > you don't really need all of that. If you include > rudimentary VRF support then you can even support > wholesale. /64 per customer, DHCPv6(-PD) server support > in the L3 switch and you're good to go. I'm curious; in these deployments, what kind of customer scale are you talking about? When someone says FTTH, I'm thinking thousands and thousands of customers, in which case not having a scalable susbcriber management system as well as not having a scalable customer termination topology could be difficult. Unless I misunderstand... > There is > equipment that already claim to do this (I never got to > test their implementation based on my requirements > because I switched jobs, but they claimed to have > implemented everything last year). Modern Metro-E switches that support full IP/MPLS in the Access have a lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than FTTH-focused, if you're talking about scale. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From swmike at swm.pp.se Thu Feb 6 14:56:15 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 15:56:15 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402061642.49646.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061608.52822.mark.tinka@seacom.mu> <201402061642.49646.mark.tinka@seacom.mu> Message-ID: On Thu, 6 Feb 2014, Mark Tinka wrote: > On Thursday, February 06, 2014 04:17:42 PM Mikael > Abrahamsson wrote: > >> You don't need a BNG. You need an L3 switch as the first >> hop the customer is talking to. > > Fine for FTTB, but not for FTTH where you're serving tens- > to-hundreds-of-thousands of customers. Why? > If your FTTH deployments are low scale (measure of low or large scale > depends on each operator's point of view), the case for doing without > subscriber management technologies can be made. Why is it different? > I'm curious; in these deployments, what kind of customer scale are you > talking about? When someone says FTTH, I'm thinking thousands and > thousands of customers, in which case not having a scalable susbcriber > management system as well as not having a scalable customer termination > topology could be difficult. Unless I misunderstand... Yes, this is for hundreds of thousands of customers. Why do you need customer management? You document where a certain fiber goes to (what port), and then this port goes to a certain customer. That is the only customer management you need. So you provision your L3 switch with a protocol based 0x86dd vlan per port, put a static /64 L3 subinterface into this vlan, then you have a built in DHCPv6(-PD) server in the same switch that hands out a static /56 on this vlan, plus hands out DNS-resolver etc. No dynamics, just static. You provision ACLs to only allow the /56, /64 and LL in on the L3 interface. You set ND cache max size to 20-50 entries per L3 subinterface to protect the 1024-2048 entries or whatever the L3 switch can handle. For IPv4 you need to do all the L2/L3-inspection magic in a common vlan. This is now a standalone unit and you don't need any central system to stay up and running in order to move IPv6 packets, and you support both directly attached computer or a residential gateway that wants PD. I did this type of DSL deplayment early 2000nds with an L3 switch and an ethernet DSLAM as media converter. This was obviously IPv4 only, but worked very well. At the same time the guys with central DHCP systems had a lot of country wide outages when the DHCP system went belly-up. I only a few years later learnt what an LNS was when I talked to someone else who did more of a "follow-the-whitepaper" deployment of DSL. > Modern Metro-E switches that support full IP/MPLS in the Access have a > lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, > but again, these are more FTTB- than FTTH-focused, if you're talking > about scale. I would never want to have MPLS that far out into the network. -- Mikael Abrahamsson email: swmike at swm.pp.se From LarrySheldon at cox.net Thu Feb 6 14:58:50 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 06 Feb 2014 08:58:50 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: <52F3A10C.3040803@cox.net> Message-ID: <52F3A32A.6080200@cox.net> >> It has been a while since I have done anything with NTP, but I would start >> with ntp.org (which didn't exist when I WAS working with it) which I am led >> to believe has the stuff that used to be at U. Delaware, like the public >> servers lists: >> >> http://support.ntp.org/bin/view/Servers/WebHome Where I found http://support.ntp.org/bin/view/Servers/PublicTimeServer000079 -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Thu Feb 6 15:02:33 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 06 Feb 2014 09:02:33 -0600 Subject: Need trusted NTP Sources In-Reply-To: <52F3A10C.3040803@cox.net> References: <52F3A10C.3040803@cox.net> Message-ID: <52F3A409.9020800@cox.net> After all these years I still can not get used to the non-standard NANOG response to "reply". I wonder if there is a way for ne to fix that locally. On 2/6/2014 8:49 AM, Larry Sheldon wrote: > On 2/6/2014 4:43 AM, Nick Hilliard wrote: >> On 06/02/2014 10:03, Notify Me wrote: >>> I'm trying to help a company I work for to pass an audit, and we've >>> been told we need trusted NTP sources (RedHat doesn't cut it). >> >> So presuming that your company is using RH or Fedora or CentOS something, >> the auditors are claiming that Red Hat, Inc is trusted enough to >> provide a >> precompiled based operating system with no feasible means of proving its >> reliability, but that they're not trustworthy enough to provide a clock >> synchronisation service? >> >> My head spins. >> >> Get new auditors. Your current ones are stupid. > > It has been a while since I have done anything with NTP, but I would > start with ntp.org (which didn't exist when I WAS working with it) which > I am led to believe has the stuff that used to be at U. Delaware, like > the public servers lists: > > http://support.ntp.org/bin/view/Servers/WebHome > > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Thu Feb 6 15:10:15 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 06 Feb 2014 09:10:15 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: <52F3A10C.3040803@cox.net> <52F3A2EA.2070508@cox.net> Message-ID: <52F3A5D7.7020904@cox.net> On 2/6/2014 9:02 AM, Nick Hilliard wrote: > On 06/02/2014 14:57, Larry Sheldon wrote: >> http://support.ntp.org/bin/view/Servers/PublicTimeServer000079 > > bear in mind that due to the vagaries of african peering weirdness, the > actual path from there to the OP's network could be over multiple satellite > links and peered in Asia, Europe or the US. The Internet in africa can be > ... odd. If it was me (having made a living getting with auditors who had no idea what they were doing) I would look for some close-by reliable (my judgement) 1- and 2- level sources (including, usually) the router at the ISP that I talk-to to get good service then add one or two the auditor likes. Larry (long time responder-to-audits that demanded that my UNIVAC and HP hardware and software look like IBM) -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From maillist at webjogger.net Thu Feb 6 15:17:53 2014 From: maillist at webjogger.net (Adam Greene) Date: Thu, 6 Feb 2014 10:17:53 -0500 Subject: carrier comparison Message-ID: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam From nanog at deman.com Thu Feb 6 15:24:17 2014 From: nanog at deman.com (Michael DeMan) Date: Thu, 6 Feb 2014 07:24:17 -0800 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: <66F884EE-08C3-4758-8160-AFEB37DA371C@deman.com> Hi Alexander, I think you or your consultant may have an overly strict reading of the PCI documents. Looking at section 10.4 of PCI DSS 3.0, and from having gone through PCI a few times... If you have your PCI hosts directly going against ntp.org or similar, then you are not in compliance. My understanding is that you need to: A) Run a local set of NTP servers - these are your 'trusted' servers, under your control, properly managed/secured, fully meshed, etc. These in turn (section 10.4.3) can get their time from 'industry-accepted time sources'. B) The rest of your PCI infrastructure in turn uses these NTP servers and only these NTP servers. - Michael DeMan On Feb 6, 2014, at 2:27 AM, Alexander Maassen wrote: > www.pool.ntp.org > > -------- Oorspronkelijk bericht -------- > Van: Notify Me > Datum: > Aan: "nanog at nanog.org list" ,afnog at afnog.org > Onderwerp: Need trusted NTP Sources > > Hi ! > > I'm trying to help a company I work for to pass an audit, and we've > been told we need trusted NTP sources (RedHat doesn't cut it). Being > located in Nigeria, Africa, I'm not very knowledgeable about trusted > sources therein. > > Please can anyone help with sources that wouldn't mind letting us sync > from them? > > Thanks a lot! > From mark.tinka at seacom.mu Thu Feb 6 15:32:14 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 17:32:14 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061642.49646.mark.tinka@seacom.mu> Message-ID: <201402061732.17441.mark.tinka@seacom.mu> On Thursday, February 06, 2014 04:56:15 PM Mikael Abrahamsson wrote: > Yes, this is for hundreds of thousands of customers. Why > do you need customer management? You document where a > certain fiber goes to (what port), and then this port > goes to a certain customer. That is the only customer > management you need. > > So you provision your L3 switch with a protocol based > 0x86dd vlan per port, put a static /64 L3 subinterface > into this vlan, then you have a built in DHCPv6(-PD) > server in the same switch that hands out a static /56 on > this vlan, plus hands out DNS-resolver etc. No dynamics, > just static. You provision ACLs to only allow the /56, > /64 and LL in on the L3 interface. You set ND cache max > size to 20-50 entries per L3 subinterface to protect the > 1024-2048 entries or whatever the L3 switch can handle. > For IPv4 you need to do all the L2/L3-inspection magic > in a common vlan. > This is now a standalone unit and you don't need any > central system to stay up and running in order to move > IPv6 packets, and you support both directly attached > computer or a residential gateway that wants PD. I won't lie, it is impressive that you strung the network this way. I can certainly see how it would work, although I'm not sure how well it would scale if you're diddling about with all sorts of kinky services beyond just access to the Internet (certinaly a concern for me, anyway). At previous job, we looked at various topologies and deployment techniques for how to support large scale FTTH installations, and one of the key issues is impact on the control plane for locally-ran DHCP servers on the routers, particularly when the same router is providing business services as well. Some vendors have seen the light and are finally running x86-based multi-core 64-bit CPU's for control plane processing, and while this may help, CPU horsepower is finite (although it would, most certainly, scale better than a Layer 3 switch doing the same thing). When you start to add services like Multicast for IPTv, and depending on whether you run these switches in a ring or not, and whether you're running Rosen MVPN vs. NG-MVPN, you can quickly start to hit platform limits or feature constraints. > I did this type of DSL deplayment early 2000nds with an > L3 switch and an ethernet DSLAM as media converter. This > was obviously IPv4 only, but worked very well. At the > same time the guys with central DHCP systems had a lot > of country wide outages when the DHCP system went > belly-up. I don't believe in centralized BNG's; mostly because traffic forwarding is not optimal. That and it's too much trust in one device. I prefer distributed BNG's (much like the topology you describe, only just less your deployment in number given how much you can scale a single Layer 3 switch to act as a service termination device). Along with distributed BNG's, you can also distribute DHCP servers, and multiple DHCP servers can maintain lease state amongst each other to allow for failover in case the primary DHCP server breaks. This is a known design tactic, and helps to take away from the issues of centralized architectures. > I would never want to have MPLS that far out into the > network. This is a different topic, but what we did was deploy MPLS all the way into the Metro-E access using Cisco's ME3600X because there had simply been to much pain doing legacy Layer 2-based Metro-E solutions (stringing VLAN's together between end points, keeping hands away from VTP, e.t.c.). This was in 2010, and by then, there wasn't any decent devices cheap enough with sufficient features to make this possible. I'd certainly recommend this architecture for Metro-E deployments focused on business-grade services. I don't expect most to follow it given there is a large Layer 2- based Metro-E installed base, but I think it will grow with time. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From vristevs at ramapo.edu Thu Feb 6 16:04:56 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Thu, 06 Feb 2014 11:04:56 -0500 Subject: carrier comparison In-Reply-To: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> Message-ID: <52F3B2A8.8080405@ramapo.edu> We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM "..caused by a power outage in a vendor data center where Cogent is collocated." They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: > Hi, > > > > We're a small ISP / datacenter with a Time Warner fiber-based DIA contract > that is coming up for renewal. > > > > We're getting much better pricing offers from Cogent, and are finding out > what Level 3 can do for us as well. Both providers will use Time Warner > fiber for last mile. > > > > My questions are: > > - Will we be sacrificing quality if we spring for Cogent? > (yesterday's Cogent/Verizon thread provided some cold chills for my spine) > > - Is there a risk with contracting a carrier that utilizes another > carrier (such as Time Warner) for the last mile? (i.e. if there is a > downtime situation, are we going to be caught in a web of confusion and > finger-pointing that delays problem resolution)? > > - How are peoples' experiences with L3 vs TWC? > > > > Although I assume everyone on the list would be interested in what others > have to say about these questions, out of respect for the carriers in > question, I encourage you to email frank opinions off list. > > > > Or if there are third party tools or resources you know that I could consult > to deduce the answers to these questions myself, they are most welcome. > > > > Thanks, > > Adam > From j at 2600hz.com Thu Feb 6 16:22:48 2014 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 6 Feb 2014 16:22:48 +0000 Subject: carrier comparison In-Reply-To: <52F3B2A8.8080405@ramapo.edu> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net>, <52F3B2A8.8080405@ramapo.edu> Message-ID: Cogent always has the cheapest rates but they also have the most peering disputes of any operator. I've seen intra-data center hops between cogent and Verizon take over 150ms. As with all things Internet, your mileage may vary. I would not put something with a 5 9'a uptime requirement on cogent without a failover circuit. For less sensitive applications it seems like a win. The Internet is both incredibly robust and fragile simultaneously. Cheers, Joshua Sent from my iPhone On Feb 6, 2014, at 8:06 AM, "Vlade Ristevski" wrote: > We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM "..caused by a power outage in a vendor data center where Cogent is collocated." They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. > > As far as price goes, for us Cogent is cheap but Lightpath is cheaper. > > Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. > > > > > > On 2/6/2014 10:17 AM, Adam Greene wrote: >> Hi, >> >> >> We're a small ISP / datacenter with a Time Warner fiber-based DIA contract >> that is coming up for renewal. >> >> >> We're getting much better pricing offers from Cogent, and are finding out >> what Level 3 can do for us as well. Both providers will use Time Warner >> fiber for last mile. >> >> >> My questions are: >> >> - Will we be sacrificing quality if we spring for Cogent? >> (yesterday's Cogent/Verizon thread provided some cold chills for my spine) >> >> - Is there a risk with contracting a carrier that utilizes another >> carrier (such as Time Warner) for the last mile? (i.e. if there is a >> downtime situation, are we going to be caught in a web of confusion and >> finger-pointing that delays problem resolution)? >> >> - How are peoples' experiences with L3 vs TWC? >> >> >> Although I assume everyone on the list would be interested in what others >> have to say about these questions, out of respect for the carriers in >> question, I encourage you to email frank opinions off list. >> >> >> Or if there are third party tools or resources you know that I could consult >> to deduce the answers to these questions myself, they are most welcome. >> >> >> Thanks, >> >> Adam >> > From patrick at ianai.net Thu Feb 6 16:28:03 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 6 Feb 2014 11:28:03 -0500 Subject: carrier comparison In-Reply-To: References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> Message-ID: <9A73070B-4593-4D8F-BC0E-13BC6E665517@ianai.net> On Feb 6, 2014, at 11:22, Joshua Goldbard wrote: > > Cogent always has the cheapest rates Objectively, provably false. -- TTFN, patrick > but they also have the most peering disputes of any operator. I've seen intra-data center hops between cogent and Verizon take over 150ms. > > As with all things Internet, your mileage may vary. I would not put something with a 5 9'a uptime requirement on cogent without a failover circuit. For less sensitive applications it seems like a win. > > The Internet is both incredibly robust and fragile simultaneously. > > Cheers, > Joshua > > Sent from my iPhone > >> On Feb 6, 2014, at 8:06 AM, "Vlade Ristevski" wrote: >> >> We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM "..caused by a power outage in a vendor data center where Cogent is collocated." They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. >> >> As far as price goes, for us Cogent is cheap but Lightpath is cheaper. >> >> Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. >> >> >> >> >> >>> On 2/6/2014 10:17 AM, Adam Greene wrote: >>> Hi, >>> >>> >>> We're a small ISP / datacenter with a Time Warner fiber-based DIA contract >>> that is coming up for renewal. >>> >>> >>> We're getting much better pricing offers from Cogent, and are finding out >>> what Level 3 can do for us as well. Both providers will use Time Warner >>> fiber for last mile. >>> >>> >>> My questions are: >>> >>> - Will we be sacrificing quality if we spring for Cogent? >>> (yesterday's Cogent/Verizon thread provided some cold chills for my spine) >>> >>> - Is there a risk with contracting a carrier that utilizes another >>> carrier (such as Time Warner) for the last mile? (i.e. if there is a >>> downtime situation, are we going to be caught in a web of confusion and >>> finger-pointing that delays problem resolution)? >>> >>> - How are peoples' experiences with L3 vs TWC? >>> >>> >>> Although I assume everyone on the list would be interested in what others >>> have to say about these questions, out of respect for the carriers in >>> question, I encourage you to email frank opinions off list. >>> >>> >>> Or if there are third party tools or resources you know that I could consult >>> to deduce the answers to these questions myself, they are most welcome. >>> >>> >>> Thanks, >>> >>> Adam > From saku at ytti.fi Thu Feb 6 16:34:13 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 6 Feb 2014 18:34:13 +0200 Subject: Need trusted NTP Sources In-Reply-To: <66F884EE-08C3-4758-8160-AFEB37DA371C@deman.com> References: <66F884EE-08C3-4758-8160-AFEB37DA371C@deman.com> Message-ID: <20140206163413.GA21496@pob.ytti.fi> On (2014-02-06 07:24 -0800), Michael DeMan wrote: > A) Run a local set of NTP servers - these are your 'trusted' servers, under your control, properly managed/secured, fully meshed, etc. I'm not sure if full-mesh is best practice, the external clients should have full view of as close to source data as possible. If in full-mesh you're already masking the data with inaccuracy, giving the clients less information to make decision? We used to have full-mesh in our meinbergs, until from their recommendation we removed it completely. It makes sense to me, but I don't understand the issue deeply. -- ++ytti From sethm at rollernet.us Thu Feb 6 16:34:44 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 06 Feb 2014 08:34:44 -0800 Subject: carrier comparison In-Reply-To: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> Message-ID: <52F3B9A4.2090103@rollernet.us> On 2/6/14, 7:17 AM, Adam Greene wrote: > Hi, > > > > We're a small ISP / datacenter with a Time Warner fiber-based DIA contract > that is coming up for renewal. > > > > We're getting much better pricing offers from Cogent, and are finding out > what Level 3 can do for us as well. Both providers will use Time Warner > fiber for last mile. > > > > My questions are: > > - Will we be sacrificing quality if we spring for Cogent? > (yesterday's Cogent/Verizon thread provided some cold chills for my spine) > > - Is there a risk with contracting a carrier that utilizes another > carrier (such as Time Warner) for the last mile? (i.e. if there is a > downtime situation, are we going to be caught in a web of confusion and > finger-pointing that delays problem resolution)? > > - How are peoples' experiences with L3 vs TWC? > > > > Although I assume everyone on the list would be interested in what others > have to say about these questions, out of respect for the carriers in > question, I encourage you to email frank opinions off list. > > > > Or if there are third party tools or resources you know that I could consult > to deduce the answers to these questions myself, they are most welcome. > > Short answer: multihome. ~Seth From jfmezei_nanog at vaxination.ca Thu Feb 6 16:38:23 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 06 Feb 2014 11:38:23 -0500 Subject: SIP on FTTH systems In-Reply-To: <201402061506.48755.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061442.43036.mark.tinka@seacom.mu> <201402061506.48755.mark.tinka@seacom.mu> Message-ID: <52F3BA7F.1050404@vaxination.ca> On 14-02-06 08:06, Mark Tinka wrote: > I'm just saying DHCP is better than PPPoE if you're > greenfielding FTTH deployments today, and I'm not sure you > entirely disagree. When an incumbent already has PPPoE deployed for its DSL, putting FTTH on PPPoE makes it simpler. And PPPoE really simplifies wholesale systems. You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE headache. We have that in Canada for cable wholesale (TPIA). The incumbent has to micromanage each ISPs IP blocks and carve subnets for each CMTS (for cable). For as much as everyone hates PPPoE, it makes for managememnt of a wholesale systems much much easier. Ideally, there would be some protocol where the CPE would setup a layer 2 SVC to the ISP, after which the ISP can provide DHCP services etc. From vristevs at ramapo.edu Thu Feb 6 16:39:01 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Thu, 06 Feb 2014 11:39:01 -0500 Subject: carrier comparison In-Reply-To: <9A73070B-4593-4D8F-BC0E-13BC6E665517@ianai.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <9A73070B-4593-4D8F-BC0E-13BC6E665517@ianai.net> Message-ID: <52F3BAA5.5090201@ramapo.edu> When I priced out providers 2 years ago for 500Mbps over 1 gig fiber link the list from most expensive to least expensive was: Verizon-->XO-->Cogent-->Lightpath This is for Northern NJ. Abovenet and some of the other big providers couldn't reach our Campus. Lightpath ate the cost of running Fiber to our campus while the other weren't willing to do that. On 2/6/2014 11:28 AM, Patrick W. Gilmore wrote: > On Feb 6, 2014, at 11:22, Joshua Goldbard wrote: >> Cogent always has the cheapest rates > Objectively, provably false. > From swmike at swm.pp.se Thu Feb 6 16:52:28 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 17:52:28 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <52F3BA7F.1050404@vaxination.ca> References: <52F31523.4000602@vaxination.ca> <201402061442.43036.mark.tinka@seacom.mu> <201402061506.48755.mark.tinka@seacom.mu> <52F3BA7F.1050404@vaxination.ca> Message-ID: On Thu, 6 Feb 2014, Jean-Francois Mezei wrote: > You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE > headache. We have that in Canada for cable wholesale (TPIA). The > incumbent has to micromanage each ISPs IP blocks and carve subnets for > each CMTS (for cable). You could have the wholesaler do DHCP inspection and antispoofing etc based on that, but not actually do the DHCP servering. > For as much as everyone hates PPPoE, it makes for managememnt of a > wholesale systems much much easier. FTTH is supposed to be for higher speeds, putting PPPoE in there makes it a lot more expensive than it has to be. > Ideally, there would be some protocol where the CPE would setup a layer > 2 SVC to the ISP, after which the ISP can provide DHCP services etc. I don't see that needed, doesn't the wholesaler already know what port has chosen what ISP and can set up L2 to that ISP? -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Thu Feb 6 17:06:16 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 19:06:16 +0200 Subject: SIP on FTTH systems In-Reply-To: <52F3BA7F.1050404@vaxination.ca> References: <52F31523.4000602@vaxination.ca> <201402061506.48755.mark.tinka@seacom.mu> <52F3BA7F.1050404@vaxination.ca> Message-ID: <201402061906.19435.mark.tinka@seacom.mu> On Thursday, February 06, 2014 06:38:23 PM Jean-Francois Mezei wrote: > When an incumbent already has PPPoE deployed for its DSL, > putting FTTH on PPPoE makes it simpler. And that is the practical issue I saw (and still see). A lot of operators just continue with it because it is maturely deployed in their networks, and attempting DHCP may not be as easy. Would I recommend trying DHCP, hell yes! > And PPPoE really simplifies wholesale systems. > You do not want the incumbent/wholesaler to perform DHCP. > This is a HUGE headache. We have that in Canada for > cable wholesale (TPIA). The incumbent has to micromanage > each ISPs IP blocks and carve subnets for each CMTS (for > cable). > > For as much as everyone hates PPPoE, it makes for > managememnt of a wholesale systems much much easier. In one country I worked, we pressured the incumbent to offer us Layer 2 backhaul instead of Layer 3, for the very same reasons. Co-managing IP address assignments, e.t.c., was problematic, especially because they were not sure how large their network was going to grow, which presented us with planning challenges in how we pre-assign address space for each of their service PoP's. Of course, because the regulator had done their job re: unbundling the fibre, they didn't care how wholesale services were actually provided over said fibre. And yes, the incumbent jumped at the chance not to offer Layer 2 backhaul, because then they knew everything we were up to (to some degree of measure). > Ideally, there would be some protocol where the CPE would > setup a layer 2 SVC to the ISP, after which the ISP can > provide DHCP services etc. Some of the vendors I've worked with don't support LNS functionality on their current generation BNG's. Just LAC. In this scenario, for PPPoE-centric operators and wholesalers, VPLS has been used to backhaul customer traffic, as opposed to L2TP, and recently, some vendors are now able to do this over EoMPLS pw's instead. If you have some control over the AN's that go into the incumben's/wholesaler's CO, you can get that Layer 2 connection (VPLS or EoMPLS pw) between your backbone and the CPE, that way. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From m.hotze at hotze.com Thu Feb 6 17:09:58 2014 From: m.hotze at hotze.com (Martin Hotze) Date: Thu, 6 Feb 2014 17:09:58 +0000 Subject: carrier comparison Message-ID: > My questions are: > > - Will we be sacrificing quality if we spring for Cogent? > (yesterday's Cogent/Verizon thread provided some cold chills for my spine) Jehova! Popcorn! :-) We used Cogent for some time. We dropped them, but not for poor quality (au contraire) but for other more complex reasons. IMHO, Cogent is far better than many say (any many of them only from 'knowledge' from word of mouth), Cogent has some oddities that you have to deal with, yust like with almost all other transit providers. Having said that: I don't want to be single homed again. hth, martin From mark.tinka at seacom.mu Thu Feb 6 08:20:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 10:20:20 +0200 Subject: Fwd: SAFNOG 2014 - Call for Papers OPEN Message-ID: <201402061020.20859.mark.tinka@seacom.mu> FYI. Mark. -------------- next part -------------- An embedded message was scrubbed... From: Chim Sichali Subject: [afnog] SAFNOG 2014 - Call for Papers OPEN Date: Tue, 28 Jan 2014 19:49:49 +0200 Size: 6648 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mlm at pixelgate.net Thu Feb 6 12:57:51 2014 From: mlm at pixelgate.net (Mark Milhollan) Date: Thu, 6 Feb 2014 04:57:51 -0800 (PST) Subject: Need trusted NTP Sources In-Reply-To: References: <42E0F0207938744EB3DA31C28FC221CFA35D32BE@LCEXMBX02.cmsad.local> Message-ID: On Thu, 6 Feb 2014, Notify Me wrote: >According to the auditors, "trusted" means > >1. Universities or Research facilities (nuclear/atomic facilities, >space research (such as NASA) etc.) >2. Main country internet/telecom providers >3. Government departments >4. Satellites (using GPS module) > >Which is a bit of a tall order over here. In general you should probably be asking . You could run your own NTP server using GPS as its reference clock (#4), at least I don't think it would be impossible for you to obtain such a device. But not cheap either. But then RHEL and an audit suggest you have some money to spend. You might even build your own using ntpd and a receiver, e.g., GNSS. See for more information. Some stratum 1 or 2 servers (which are generally run by entities 1 thru 3 from your list) may allow you to obtain time (perhaps using crypto), but of course you'd need to contact them directly. ntp.org has a list: . Generally speaking, you'll need at least 3 sources if you want stablity. Mark From effulgence at gmail.com Thu Feb 6 16:45:46 2014 From: effulgence at gmail.com (Aris Lambrianidis) Date: Thu, 6 Feb 2014 17:45:46 +0100 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <20140205135203.GA594@pfrc> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> <52E40476.20200@foobar.org> <5F21101E-7148-4323-8214-7A2DC49AE1CE@pfrc.org> <20140205100631.479da729@fizzix> Message-ID: <20140206164546.GA18386@tangental.net> Food for thought: - ASNs can be reused at different locations by IXPs, barring perhaps certain business or administrative reasons. Ask Equinix. - For IXPs that already have 16-bit ASNs for route servers, this saves additional allocations from RIRs and mitigates concerns for the IXP getting potentially a 32-bit ASN, thus having trouble with BGP communities as described. Having a single ASN may raise other issues but it is an option. - I believe it would help if RIRs reserved 16-bit ASNs in addition to IPv4 micro allocations for IXPs, until a formal solution can be finally found about the 32-bit ASN BGP communities issue. Aris Lambrianidis From anders at abundo.se Thu Feb 6 17:41:34 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Thu, 06 Feb 2014 18:41:34 +0100 Subject: SIP on FTTH systems In-Reply-To: <201402061608.52822.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> <201402061608.52822.mark.tinka@seacom.mu> Message-ID: <52F3C94E.9010209@abundo.se> On 2014-02-06 15:08, Mark Tinka wrote: >> You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection.... > > If you have a reasonably intelligent AN (like some of > today's Active-E devices), you can create so-called split > horizons on the same bridge domain (VLAN, really) where > customers will only communicate via the upstream BNG at > Layer 3. > > At Layer 2, even though they are all sitting on the same > VLAN, there is no inter-communication between them. Ok, then you have not understood the problem with IPv6 in shared VLANs. You need to allow some communication between the user ports on L2, to get the IPv6 control procotol to work. You do this on IPv4 today, with proxy arp etc. Its much more complex in IPv6. > I've also know Huawei OLT's support these split horizons too. Many devices support what Cisco calls Private VLAN or MACFF as specificed in RFC4562. There are IPv4 only implementations today - but not all these protocols are standardized, and are not interoperable between vendors. I have still not heard of any vendor shipping the same functionality to share VLANs with IPv6, in a secure way. >> Or do something bold, run L3 at the edge :) > > Cheap switches that have decent IP/MPLS support are mostly > geared toward Metro-E deployments, i.e., business-grade > services. So they are quite poor with regard to susbcriber > management features and capabilities. You need a basic L3 access switch, with some tweaks. I've been working at and designing such devices for seven years at my former employeer PacketFront Networks. Whole bunch of standard protocols. OSPF, PIM-SM, IGMPv2/v3 in the edge, and now with OSPFv3, PIM-SMv6 and MLD/MLDv2. DHCPv4/v6 is relayed to the correct service provider, unless its management traffic and should be handled by the network. Very easy, very few security issues since no L2 is allowed between customers, no strange protocols (ARP inspection, proxy ARP, IP source guard, DHCP Snooping/option82 or their IPv6 counterparts). Open-access is done on the L3 layer, no VLANs. There are free seating in the CPE so all equipment in the home can talk to each other. Important with todays DLNA/TV sets and mobile phones. It is very scalable, since that is how Internet is built :) Of course, it needs a proper management system, so we built one as well. We also pushed Python into the access device, so DHCPv4/DHCPv6, radius, 802.1x functionality and how those are used can easily be adjusted in a script instead of trying to express programming in a CLI. On top of that some simple templates describing the services. The radius server just returns the service name with needed parameters (bandwidth, priority etc) and the python script installs/removes instances of the service as needed. I promise this access device has NO problems with spoofed packets, see the BCP38 discussion :) So, it's a small BNG in the access device. And no, it's not that expensive. We did look at sourcing a L2 switch from Taiwan, we could get the switch with L2 or L3 forwarding in a Broadcom switch ASIC, all the other features was equal. Cost difference was five dollars. (PacketFronts access device uses a NPU, much more flexible) Vendors charging both an arm and a leg for routers are doing that because they can, doing L3 is not more expensive than L2 with todays technology. PacketFront has sold over 1 miljon ports, and the largest installation is >50000 ports, both in Sweden, Holland and Dubai. This can easily scale to much bigger networks. The biggest issue with selling L3 to the edge is not technical or economical, its religious - people are just so used to build their networks in a specific way and they don't want to change.... /Anders From swmike at swm.pp.se Thu Feb 6 19:04:40 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Feb 2014 20:04:40 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <52F3C94E.9010209@abundo.se> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> <201402061608.52822.mark.tinka@seacom.mu> <52F3C94E.9010209@abundo.se> Message-ID: On Thu, 6 Feb 2014, Anders L?winger wrote: > Ok, then you have not understood the problem with IPv6 in shared VLANs. > You need to allow some communication between the user ports on L2, to > get the IPv6 control procotol to work. You do this on IPv4 today, with > proxy arp etc. Its much more complex in IPv6. No, you don't. It works perfectly well without direct port-to-port communication, you just have to align L3 configuration with this L2 behavior (which can be done in IPv6 but not in IPv4). IPv6 can be made to work without on-link /64, with only DHCPv6 IA_NA (optional) and only DHCPv6-PD. This means all communication goes via the router which then is perfectly aligned with how the L2 looks like with port isolation/private vlan. -- Mikael Abrahamsson email: swmike at swm.pp.se From ckeladis at gmail.com Thu Feb 6 19:21:35 2014 From: ckeladis at gmail.com (Chris Keladis) Date: Fri, 7 Feb 2014 06:21:35 +1100 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 9:03 PM, Notify Me wrote: I'm trying to help a company I work for to pass an audit, and we've > been told we need trusted NTP sources (RedHat doesn't cut it). Being > located in Nigeria, Africa, I'm not very knowledgeable about trusted > sources therein. > Obviously "trusted" time sources are important, but at the end of the day you have to trust someone who ultimately has the least risk (there is never no risk) you are able to achieve. I appreciate "least level of risk" is subjective to your auditors opinion (in this case) :-) Just wanted to mention, having a good number of servers (not blindly trusting <= 3 unique sources) adds some additional protection against 'false-tickers'. Even "trusted" time-sources have their off-days due to a myriad of technical reasons. Configure multiple, relatively high stratum (taking into account how many stratum's you intend to serve downstream), low-jitter/rtt, good-quality, time-sources. Also, risk changes over time, so vigilant monitoring is important too! Regards, Chris. From mysidia at gmail.com Thu Feb 6 19:25:47 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 6 Feb 2014 13:25:47 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 8:28 AM, jamie rishaw wrote: > PCI DSS only requires that all clocks be synchronized; It doesn't > /require/ "how". > If you read requirement 10.4 more carefully, you will find that it Does require that time be synchronized from an INDUSTRY ACCEPTED external time source. The GPS reference clock, a radio timecode receiver, receiving NIST or USNO, Microsoft's time source (time.windows.com), Redhat's time source, various univerisities and other public time servers listed on NTP.org, the NIST time servers listed here: http://tf.nist.gov/tf-cgi/servers.cgi Are among the INDUSTRY ACCEPTED external time sources. This is not an exhaustive enumeration of industry-accepted external time sources. -- -JH From mark.tinka at seacom.mu Thu Feb 6 19:49:43 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 21:49:43 +0200 Subject: SIP on FTTH systems In-Reply-To: <52F3C94E.9010209@abundo.se> References: <52F31523.4000602@vaxination.ca> <201402061608.52822.mark.tinka@seacom.mu> <52F3C94E.9010209@abundo.se> Message-ID: <201402062149.47240.mark.tinka@seacom.mu> On Thursday, February 06, 2014 07:41:34 PM Anders L?winger wrote: > Ok, then you have not understood the problem with IPv6 in > shared VLANs. You need to allow some communication > between the user ports on L2, to get the IPv6 control > procotol to work. You do this on IPv4 today, with proxy > arp etc. Its much more complex in IPv6. No, it's not, and no, you don't. Active-E and GPON AN's support split horizons where shared VLAN's allow for simple service delivery to the CPE, but do not permit inter-customer communications at Layer 2. All communications happens upstream at the BNG, which works for IPv4 and IPv6. And no, Proxy ARP is recommended for my competitors. If you're not my competitor, suggest you turn it off if you want happiness. > Many devices support what Cisco calls Private VLAN or > MACFF as specificed in RFC4562. There are IPv4 only > implementations today - but not all these protocols are > standardized, and are not interoperable between vendors. > I have still not heard of any vendor shipping the same > functionality to share VLANs with IPv6, in a secure way. And that is why for modern Active-E kit, I prefer to enable split horizons using split horizon tech. against bridge domains, rather than Private VLAN's. Private VLAN's have lots of restrictions, and on AN's that support EVC (Cisco- style), you can enable split horizons on bridge domains, which works perfectly for Layer 2 and Layer 3 traffic. > PacketFront has sold over 1 miljon ports, and the largest > installation is > > >50000 ports, both in Sweden, Holland and Dubai. This > >can easily scale to > > much bigger networks. The system specs. are impressive - basically, a little BNG in a switch, which I can't complain with. I suppose if I'm a business that wants to consolidate BNG and business services on a single platform, the existing routers I pay big money for to enable those business servics can double as BNG's. It's distributed, uniform and a single place where I can offer multiple services to different types of customers. But, if I'm a business with a low start-up budget focused on broadband services, or lots of cash with no plans to break into the enterprise or service provider markets, the PacketFront make sense. My only concern would be NG-MVPN support - does the PacketFront have that? > The biggest issue with selling L3 to the edge is not > technical or economical, its religious - people are just > so used to build their networks in a specific way and > they don't want to change.... Well: - I support DHCP instead of PPPoE for subscriber management. - I support decentralized rather than centralized BNG's. - I support Active-E rather than GPON. These are all relatively less-than-popular scenarios based on many of the deployments I've seen in previous years. So while I agree that there is a healthy amount of religion to these things, there is also room for change if the reasons are compelling. But yes, it can come down to personal taste by one person in the company. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Feb 6 19:50:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 6 Feb 2014 21:50:10 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <52F3C94E.9010209@abundo.se> Message-ID: <201402062150.10572.mark.tinka@seacom.mu> On Thursday, February 06, 2014 09:04:40 PM Mikael Abrahamsson wrote: > No, you don't. It works perfectly well without direct > port-to-port communication, you just have to align L3 > configuration with this L2 behavior (which can be done > in IPv6 but not in IPv4). > > IPv6 can be made to work without on-link /64, with only > DHCPv6 IA_NA (optional) and only DHCPv6-PD. This means > all communication goes via the router which then is > perfectly aligned with how the L2 looks like with port > isolation/private vlan. Yep. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From fkittred at gwi.net Thu Feb 6 20:27:09 2014 From: fkittred at gwi.net (Fletcher Kittredge) Date: Thu, 6 Feb 2014 15:27:09 -0500 Subject: SIP on FTTH systems In-Reply-To: <52F31523.4000602@vaxination.ca> References: <52F31523.4000602@vaxination.ca> Message-ID: On Wed, Feb 5, 2014 at 11:52 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > Quick question: > > In the USA, do CLECs have access to homes served only by FTTH ? If so, > how it is accomplisehd ? > > In practice CLECs do not have access. The TR order of the last decade mandated that access via FTTH was not a section 251 requirement under the Telco Act of 1996 except for a 64kbs stream which in theory could be used for voice. However, I believe there has been no widescale use of that feature because it is uneconomical compared to "over-the-top" VoIP. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From bicknell at ufp.org Thu Feb 6 20:54:25 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 6 Feb 2014 14:54:25 -0600 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140205084657.GA22744@pob.ytti.fi> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <20140205084657.GA22744@pob.ytti.fi> Message-ID: <9D65598A-53C3-4749-A753-461163B28F9D@ufp.org> On Feb 5, 2014, at 2:46 AM, Saku Ytti wrote: > If we keep thinking this problem as last-mile port problem, it won't be solved > in next 20 years. Because lot of those ports really can't do RPF and even if > they can do it, they are on autopilot and next change is market forced > fork-lift change. Company may not even employ technical personnel, only buy > consulting when making changes. It can be solved, but not by NANOG. Imagine if Cable labs required all DOCSIS compliant cable modems to default to doing source address verification in the next version of DOCSIS? It would (eventually) get rolled out, and it would solve the problem. Even if it doesn't default to on, requiring the hardware to be capable would be a nice step. The consumer last mile is actually simpler in that there are a few organizations who "control" the standards. Efforts need to focus on getting the BCP38 stuff into those standards, ideally as mandatory defaults. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mksmith at mac.com Thu Feb 6 20:54:30 2014 From: mksmith at mac.com (Michael Smith) Date: Thu, 06 Feb 2014 12:54:30 -0800 Subject: TWC (AS11351) blocking all NTP? In-Reply-To: References: <20140202040319.GD24634@hijacked.us> <20140202163313.GF24634@hijacked.us> <5F8CF927-1096-4A86-BF97-72E74A873941@puck.nether.net> Message-ID: On Feb 4, 2014, at 8:52 AM, William Herrin wrote: > On Tue, Feb 4, 2014 at 11:23 AM, Jared Mauch wrote: >> On Feb 4, 2014, at 11:04 AM, William Herrin wrote: >>> If just three of the transit-free networks rewrote their peering >>> contracts such that there was a $10k per day penalty for sending >>> packets with source addresses the peer should reasonably have known >>> were forged, this problem would go away in a matter of weeks. > >> I've seen similar comments in other forums. We are all generally paid >> for moving packets, not filtering them. The speed at which you can forward >> packets can often cause increased $$. Using these features also impacts >> performance, so the cost may actually be 2x in capex+opex to provision ports >> due to reduced line-rate capability. > > Hi Jared, > > You're gonna need a bigger TCAM, but even so I think you're > overstating the case. No, he's not. The intelligence required to analyze packets is in addition to the intelligence required to move them. More packets, more cost. > > >> Even if you take a RPSL-IRR approach to building filters, and even if the router >> can handle such long ACLs bug-free, you have some objects that expand to >> cover 50-90% of the internet. They may be someones backup route at some >> point because of 'something'. > > Yes, but that's OK. In order to make sure that they're aren't > originating from the penalizing 10%, your peers will have to implement > similar filtering downstream... where the breadth isn't 90%. > > So who determines this break point? Who is responsible for a full-table Tier-1 to Tier-1 peering link? Who polices it? Who arbitrates disputes? >> Clearly putting the filters as close to the source is helpful but detecting the >> actual spoofed packet is hard. > > At the customer boundary it's trivial: they'll tell you what they > originate, and that's what you'll allow. If your customer lies, pass > the penalty forward. > > At the peering boundary, you don't have to detect the forged packets. > You can wait until someone complains, confirm it, and then apply the > penalty. Packets coming from your peers won't > go to your other peers, only to your customers. That's how you rigged > your routing. More, evidence that the downstream was authorized to > send those packets refutes the penalty. > > You know this is completely unworkable at scale right? >> Until you find yourself on the receiving end of these types of things, you may not >> ask for or pay for DDoS protection services, or advanced filtering, or even ask >> your vendor to support these features. I have to wait months for fixes in the >> features because no support from others in the industry on the platform, etc. > > DDoS is a bigger problem than spoofing and amplification. My > suggestion only addresses spoofing and amplification, not botnets in > general. > But they have the same economic inputs, yes? As Jared said, providers get paid by the bit. Many (most?) Bad Actors get paid by the bit, Vendors get paid by the bit, mitigation vendors get paid by the bit. That's a lot of dollars for a lot of bits and they increase together. > >> Those that are up in arms about this stuff seem to not be the ones asking >> the vendors for features and fixes. > > Like I said, the "tier 1's" can't be the source of the solution until > they stop being part of the problem. > You are asking the guys who build and maintain the highways to be responsible for checking every car on the road to see if it's carrying illegal drugs. How can that possibly work? Mike From matthew at corp.crocker.com Thu Feb 6 21:22:56 2014 From: matthew at corp.crocker.com (Matthew Crocker) Date: Thu, 6 Feb 2014 16:22:56 -0500 Subject: carrier comparison In-Reply-To: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> Message-ID: <42795598-D280-4CE9-99B2-81A9454559E1@corp.crocker.com> IMHO Cogent bandwidth is fine so long as it isn?t your only bandwidth. Good, Cheap, Fast, Pick any two. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Feb 6, 2014, at 10:17 AM, Adam Greene wrote: > Hi, > > > > We're a small ISP / datacenter with a Time Warner fiber-based DIA contract > that is coming up for renewal. > > > > We're getting much better pricing offers from Cogent, and are finding out > what Level 3 can do for us as well. Both providers will use Time Warner > fiber for last mile. > > > > My questions are: > > - Will we be sacrificing quality if we spring for Cogent? > (yesterday's Cogent/Verizon thread provided some cold chills for my spine) > > - Is there a risk with contracting a carrier that utilizes another > carrier (such as Time Warner) for the last mile? (i.e. if there is a > downtime situation, are we going to be caught in a web of confusion and > finger-pointing that delays problem resolution)? > > - How are peoples' experiences with L3 vs TWC? > > > > Although I assume everyone on the list would be interested in what others > have to say about these questions, out of respect for the carriers in > question, I encourage you to email frank opinions off list. > > > > Or if there are third party tools or resources you know that I could consult > to deduce the answers to these questions myself, they are most welcome. > > > > Thanks, > > Adam > > From sam at circlenet.us Thu Feb 6 21:30:39 2014 From: sam at circlenet.us (Sam Moats) Date: Thu, 06 Feb 2014 16:30:39 -0500 Subject: carrier comparison In-Reply-To: <42795598-D280-4CE9-99B2-81A9454559E1@corp.crocker.com> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <42795598-D280-4CE9-99B2-81A9454559E1@corp.crocker.com> Message-ID: <100e1a60498aeba95966f46972f84f54@www.circlenet.us> +1 Same feeling here. Sam Moats On 2014-02-06 16:22, Matthew Crocker wrote: > IMHO Cogent bandwidth is fine so long as it isn?t your only > bandwidth. Good, Cheap, Fast, Pick any two. > > > -- > Matthew S. Crocker > President > Crocker Communications, Inc. > PO BOX 710 > Greenfield, MA 01302-0710 > > E: matthew at crocker.com > P: (413) 746-2760 > F: (413) 746-3704 > W: http://www.crocker.com > > > > On Feb 6, 2014, at 10:17 AM, Adam Greene > wrote: > >> Hi, >> >> >> >> We're a small ISP / datacenter with a Time Warner fiber-based DIA >> contract >> that is coming up for renewal. >> >> >> >> We're getting much better pricing offers from Cogent, and are >> finding out >> what Level 3 can do for us as well. Both providers will use Time >> Warner >> fiber for last mile. >> >> >> >> My questions are: >> >> - Will we be sacrificing quality if we spring for Cogent? >> (yesterday's Cogent/Verizon thread provided some cold chills for my >> spine) >> >> - Is there a risk with contracting a carrier that utilizes >> another >> carrier (such as Time Warner) for the last mile? (i.e. if there is a >> downtime situation, are we going to be caught in a web of confusion >> and >> finger-pointing that delays problem resolution)? >> >> - How are peoples' experiences with L3 vs TWC? >> >> >> >> Although I assume everyone on the list would be interested in what >> others >> have to say about these questions, out of respect for the carriers >> in >> question, I encourage you to email frank opinions off list. >> >> >> >> Or if there are third party tools or resources you know that I could >> consult >> to deduce the answers to these questions myself, they are most >> welcome. >> >> >> >> Thanks, >> >> Adam >> >> From ikiris at gmail.com Thu Feb 6 21:32:50 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 6 Feb 2014 15:32:50 -0600 Subject: carrier comparison In-Reply-To: <42795598-D280-4CE9-99B2-81A9454559E1@corp.crocker.com> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <42795598-D280-4CE9-99B2-81A9454559E1@corp.crocker.com> Message-ID: I use Cogent as well, no real issues other than I wouldn't single home to them. Personally, I don't understand why someone would depend on a single provider for connectivity however... -Blake On Thu, Feb 6, 2014 at 3:22 PM, Matthew Crocker wrote: > > > IMHO Cogent bandwidth is fine so long as it isn't your only bandwidth. > Good, Cheap, Fast, Pick any two. > > > -- > Matthew S. Crocker > President > Crocker Communications, Inc. > PO BOX 710 > Greenfield, MA 01302-0710 > > E: matthew at crocker.com > P: (413) 746-2760 > F: (413) 746-3704 > W: http://www.crocker.com > > > > On Feb 6, 2014, at 10:17 AM, Adam Greene wrote: > > > Hi, > > > > > > > > We're a small ISP / datacenter with a Time Warner fiber-based DIA > contract > > that is coming up for renewal. > > > > > > > > We're getting much better pricing offers from Cogent, and are finding out > > what Level 3 can do for us as well. Both providers will use Time Warner > > fiber for last mile. > > > > > > > > My questions are: > > > > - Will we be sacrificing quality if we spring for Cogent? > > (yesterday's Cogent/Verizon thread provided some cold chills for my > spine) > > > > - Is there a risk with contracting a carrier that utilizes > another > > carrier (such as Time Warner) for the last mile? (i.e. if there is a > > downtime situation, are we going to be caught in a web of confusion and > > finger-pointing that delays problem resolution)? > > > > - How are peoples' experiences with L3 vs TWC? > > > > > > > > Although I assume everyone on the list would be interested in what others > > have to say about these questions, out of respect for the carriers in > > question, I encourage you to email frank opinions off list. > > > > > > > > Or if there are third party tools or resources you know that I could > consult > > to deduce the answers to these questions myself, they are most welcome. > > > > > > > > Thanks, > > > > Adam > > > > > > > From eric at flanery.us Thu Feb 6 21:57:02 2014 From: eric at flanery.us (Eric Flanery (eric)) Date: Thu, 6 Feb 2014 13:57:02 -0800 Subject: carrier comparison In-Reply-To: <52F3B2A8.8080405@ramapo.edu> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> Message-ID: Vlade, When you say that "they still advertise your routes", do you mean: A: That you were having them originate your routes, and they failed to stop doing so when they had problems? Or... B: That routes you were originating continued to be propagated by them, even though your session with them was down? Or... C: Something else. I ask, as we are considering some cheap Cogent bandwidth in the not-too-distant future, to allow us to keep commit rates low on higher quality connections. 'A' wouldn't be a real problem, since we run our own AS and originate our own routes; 'B' could be potentially devastating. On Thu, Feb 6, 2014 at 8:04 AM, Vlade Ristevski wrote: > We have had Cogent over Verizon's Fiber for more than a few years now. > Cogent goes down once at year at minimum. They had 2 outages in a single > day a couple days ago in Northern NJ. One in the AM "..caused by a power > outage in a vendor data center where Cogent is collocated." They went on to > have another outage at around 9:30 PM on the same day for which I'm still > waiting for an RFO. During this outage, they still were advertising our BGP > routes so we didn't fail over to our 2nd provider. I notice that happens > alot with them. When they go down, they still advertise your routes. > > As far as price goes, for us Cogent is cheap but Lightpath is cheaper. > > Our college is kind of far from things so we don't have a lot of outside > fiber coming. The last mile fiber for both of our connections are different > from our Internet providers. I've never had a big issue with the two > working with each other. The only issue we had is I suspected we weren't > getting as much bandwidth as we paid for. They had to work out where the > policer and/or bottle neck was. This is the only issue we had in 5 years > with this set up and it got resolved. IME, when there is a full outage, > it's always been clear who the responsible party is. > > > > > > > On 2/6/2014 10:17 AM, Adam Greene wrote: > >> Hi, >> >> >> We're a small ISP / datacenter with a Time Warner fiber-based DIA contract >> that is coming up for renewal. >> >> >> We're getting much better pricing offers from Cogent, and are finding out >> what Level 3 can do for us as well. Both providers will use Time Warner >> fiber for last mile. >> >> >> My questions are: >> >> - Will we be sacrificing quality if we spring for Cogent? >> (yesterday's Cogent/Verizon thread provided some cold chills for my spine) >> >> - Is there a risk with contracting a carrier that utilizes >> another >> carrier (such as Time Warner) for the last mile? (i.e. if there is a >> downtime situation, are we going to be caught in a web of confusion and >> finger-pointing that delays problem resolution)? >> >> - How are peoples' experiences with L3 vs TWC? >> >> >> Although I assume everyone on the list would be interested in what others >> have to say about these questions, out of respect for the carriers in >> question, I encourage you to email frank opinions off list. >> >> >> Or if there are third party tools or resources you know that I could >> consult >> to deduce the answers to these questions myself, they are most welcome. >> >> >> Thanks, >> >> Adam >> >> > From vristevs at ramapo.edu Thu Feb 6 22:25:53 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Thu, 06 Feb 2014 17:25:53 -0500 Subject: carrier comparison In-Reply-To: References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> Message-ID: <52F40BF1.8030807@ramapo.edu> B) We have our own AS and IP space. I advertise them to both Cogent and our other ISP. I use the local preference attribute to share the load for incoming traffic between both ISPs. In the last 5 outages over the last few years, this has happened twice. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too. It sucks for us, because we're a small school and don't have someone in a NOC to monitor our networks 24x7. I literally had to get out of bed and disable our BGP session with them for us to get through the outage. I was getting around 90% packet loss from my home to our router. On 2/6/2014 4:57 PM, Eric Flanery (eric) wrote: > Vlade, > > When you say that "they still advertise your routes", do you mean: > > A: That you were having them originate your routes, and they failed to > stop doing so when they had problems? Or... > > B: That routes you were originating continued to be propagated by > them, even though your session with them was down? Or... > > C: Something else. > > I ask, as we are considering some cheap Cogent bandwidth in the > not-too-distant future, to allow us to keep commit rates low on higher > quality connections. 'A' wouldn't be a real problem, since we run our > own AS and originate our own routes; 'B' could be potentially devastating. > > > On Thu, Feb 6, 2014 at 8:04 AM, Vlade Ristevski > wrote: > > We have had Cogent over Verizon's Fiber for more than a few years > now. Cogent goes down once at year at minimum. They had 2 outages > in a single day a couple days ago in Northern NJ. One in the AM > "..caused by a power outage in a vendor data center where Cogent > is collocated." They went on to have another outage at around 9:30 > PM on the same day for which I'm still waiting for an RFO. During > this outage, they still were advertising our BGP routes so we > didn't fail over to our 2nd provider. I notice that happens alot > with them. When they go down, they still advertise your routes. > > As far as price goes, for us Cogent is cheap but Lightpath is cheaper. > > Our college is kind of far from things so we don't have a lot of > outside fiber coming. The last mile fiber for both of our > connections are different from our Internet providers. I've never > had a big issue with the two working with each other. The only > issue we had is I suspected we weren't getting as much bandwidth > as we paid for. They had to work out where the policer and/or > bottle neck was. This is the only issue we had in 5 years with > this set up and it got resolved. IME, when there is a full outage, > it's always been clear who the responsible party is. > > > > > > > On 2/6/2014 10:17 AM, Adam Greene wrote: > > Hi, > > > We're a small ISP / datacenter with a Time Warner fiber-based > DIA contract > that is coming up for renewal. > > > We're getting much better pricing offers from Cogent, and are > finding out > what Level 3 can do for us as well. Both providers will use > Time Warner > fiber for last mile. > > > My questions are: > > - Will we be sacrificing quality if we spring for Cogent? > (yesterday's Cogent/Verizon thread provided some cold chills > for my spine) > > - Is there a risk with contracting a carrier that > utilizes another > carrier (such as Time Warner) for the last mile? (i.e. if > there is a > downtime situation, are we going to be caught in a web of > confusion and > finger-pointing that delays problem resolution)? > > - How are peoples' experiences with L3 vs TWC? > > > Although I assume everyone on the list would be interested in > what others > have to say about these questions, out of respect for the > carriers in > question, I encourage you to email frank opinions off list. > > > Or if there are third party tools or resources you know that I > could consult > to deduce the answers to these questions myself, they are most > welcome. > > > Thanks, > > Adam > > > -- Vlad From lists at mtin.net Fri Feb 7 00:44:16 2014 From: lists at mtin.net (Justin Wilson) Date: Thu, 06 Feb 2014 19:44:16 -0500 Subject: AT&T Security Message-ID: Anyone have a contact for AT&T security? I have a Denial of service attack going on for a customer with an AT&T Fiber Circuit. I called AT&T and they gave me an 888 number which is some security contractor. Justin -- Justin Wilson MTCNA ? CCNA ? MTCRE ? MTCWE - COMTRAIN Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.zigwireless.com ? High Speed Internet Options http://www.thebrotherswisp.com ? The Brothers Wisp From leo.vegoda at icann.org Fri Feb 7 00:49:02 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 6 Feb 2014 16:49:02 -0800 Subject: FW: Trusted Community Representation for Root KSK In-Reply-To: <5061C938-FBCE-4DE1-BD4A-E996A1DDC4D3@icann.org> References: <5061C938-FBCE-4DE1-BD4A-E996A1DDC4D3@icann.org> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19684A12437@EXVPMBX100-1.exc.icann.org> Hi, People on this list might also want to submit responses. Regards, Leo From: dns-operations-bounces at mail.dns-oarc.net [mailto:dns-operations-bounces at mail.dns-oarc.net] On Behalf Of Kim Davies Sent: Thursday, February 06, 2014 12:38 PM To: DNS Operations Subject: [dns-operations] Trusted Community Representation for Root KSK Hi folks, ICANN is currently performing a consultation on how to evolve the participation of Trusted Community Representatives in the management of the root key signing key. I think this consultation is of particular interest to this group as ultimately these TCRs are there to instill trust in the DNS operations community that the KSK is being managed in a proper fashion. I'd encourage you to provide feedback to this consultation - available at http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan 14-en.htm - by 11th February. It is important we have a model of TCR participation that is satisfactory to the community. For convenience, here are the terms of reference replicated: Background Since July 2010, the DNS Root Zone has been secured using DNSSEC[1]. The model of using DNSSEC in the DNS Root Zone revolves around a "key signing key" (KSK) that is managed by ICANN in two secure facilities. Four times a year, a ceremony is conducted at these facilities to perform operations involving the KSK. As a key part of this process, a minimum of three from a pool of 21 trusted community representatives (TCRs) attend each ceremony to enable access to the secure materials, to witness the procedure, and to attest that the ceremony was conducted properly[2]. Each ceremony is attended by ICANN staff, the TCRs, representatives of the Root Zone Maintainer (Verisign), representatives of an independent audit firm retained by ICANN to monitor the process, and often additional external witnesses. Ceremonies are recorded by three audit cameras and webcast online. A typical ceremony lasts approximately four hours, and involves a process of temporarily removing the key signing key from a safe and performing key-signing operations in a secure manner following a formal script. The script is designed to perform each operation in a transparent manner to ensure the key signing key is only used for its proper purpose, and there is no ability for its contents to be disclosed for other purposes. Materials from each ceremony - such as the scripts, video recordings, and system output - are posted online[3]. De-briefings and discussions are conducted post-ceremony, where participants discuss how to improve future ceremonies. This feedback helps inform the evolution of the KSK ceremony to be both efficient and effective, while ensuring maximum trust in how ceremonies are performed. The TCRs were selected[4] from the global community based on a number of criteria[5]. These selection criteria relate to the volunteers ability to travel to ceremonies, conscientiously oversee the process, ensure transparency in its operation, and ultimately contribute to the broader community's trust that the private component of the key signing key has not been compromised. The TCRs are privately funded volunteers who are not reimbursed or compensated by ICANN for their participation nor their expenses. The original TCR proposal was silent on the length of service of individual TCRs. Of the 21 TCRs, seven are credentialed as "crypto officers" (COs) for each of the two facilities, and the remaining seven act as "recovery key shareholders" who only participate in ceremonies in the event the requisite number of COs are unable to participate or there is a need to rebuild the KSK following an unforeseen event. Of the seven COs for each facility, ICANN aims to have four attend each ceremony, with an absolute minimum of three required to successfully perform a ceremony. Each facility hosts two ceremonies per year, approximately once every six months. In practice, a TCR will attend at minimum one ceremony per year, and some will attend two in order to ensure sufficient attendance. Of the initial pool of 21 TCRs, one has resigned and been replaced from the pool of recovery key shareholders. No TCR has been removed owing to the other three criteria for replacement in the TCR selection document, relating to lack of integrity or trustworthiness; assumption of a conflicting role within a root management organization; or being unable to serve in their position. Based on feedback from the current TCRs and our experience from the first 14 ceremonies, we are reviewing what changes, if any, should be made to the current model of TCR participation. Comments Comments are welcome on any aspect of the consultation, and specifically on the following questions: 1. Is the current TCR model effectively performing its function of ensuring trust in the KSK management process? 2. Is the current size of the TCR pool appropriate to ensure sufficient participation in the ceremonies, while not overburdening the availability of specific volunteers? 3. Should there be a minimum level of participation required of a TCR in order to be considered to be successfully discharging their duties? 4. There is no standard provision to refresh the list of TCRs except when they are replaced due to inability to effectively perform their function. Should there be a process to renew the pool of TCRs, such as using term limits or another rotation mechanism? 5. The current model does not compensate TCRs for their services in order to ensure their independence from ICANN. a. Should the model of TCRs paying the costs of their participation be retained? b. Would some form of compensation to offset the expenses incurred by the TCRs detract from their independence in performing the role? c. If you support compensating TCRs for their expenses, are there requirements or limitations on whom the funding organization should be? Please send your comments to comments-tcr-dnssec-key-signing-21jan14 at icann.org References [1] http://www.root-dnssec.org [2] https://www.iana.org/dnssec/icann-dps.txt [3] http://data.iana.org/ksk-ceremony/ [4] http://www.root-dnssec.org/tcr/selection-2010/ [5] http://www.root-dnssec.org/wp-content/uploads/2010/04/ICANN-TCR-Proposal -20100408.pdf kim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From alh-ietf at tndh.net Fri Feb 7 02:09:17 2014 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 6 Feb 2014 18:09:17 -0800 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: <064101cf23a9$a7752070$f65f6150$@tndh.net> > -----Original Message----- > From: Notify Me [mailto:notify.sina at gmail.com] > Sent: Thursday, February 06, 2014 4:54 AM > To: Aled Morris > Cc: nanog at nanog.org; Martin Hotze > Subject: Re: Need trusted NTP Sources > > Raspberries! Not common currency here either, but let's see! While I would be using a Pi if I were doing it now, a few years ago I put together a circuit that used a <$100 outdoor mast-mount GPS receiver* with a PPS out, to feed an RS232 connection to 3 FreeBSD 8.1 systems compiled with: options PPS_SYNC # I don't know if that is still required in 10.0, and I understand Linux has since fixed the kernel time resolution issues it was having, so research into current OS configuration is required. To make the local time reference preferred over external references, in ntp conf: server 127.127.20.1 mode 8 minpoll 4 maxpoll 4 prefer The diagram is at http://tndh.net/~tony/GPS-PPS-5v-ttl_232-box.pdf While there is 'some assembly required', the components to feed existing servers may be easier to come by than a Pi, and an outdoor receiver will have better reception than the Adafruit one stuck inside a datacenter. As others have said, several external references help protect against any one source having a bad day, but you should also be aware that network asymmetry WILL impact your results so factor topology into your source selection. Using this setup and OWAMP** I was able to track down a ~20ms "peering asymmetry" between HE & Comcast "inside the Seattle Westin colo", which still persists.*** It would appear from the time delay that one of their intermediaries is not really present in the building, but using a fiber loop to a city about 400 miles away (Boise, or Medford ??). I am not aware of the specific topology, other than traceroute shows different intermediaries in each direction at one IP hop, with one taking 20ms longer than the other to move between the same HE & Comcast routers inside that colo. What I can see is the impact it has of showing the IPv6 connected NTP peers as ~10ms off of the local IPv4 ones & the GPS receiver. Good luck * MR-350P http://www.amazon.com/Globalsat-Waterproof-External-Receiver-without/dp/B001 ENYWJC/ref=sr_sp-atf_title_1_1?ie=UTF8&qid=1391734470&sr=8-1&keywords=mr-350 p ** OWAMP >>> http://software.internet2.edu/owamp/ *** >ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================ == xPPS(1) .PPS. 0 l 7 16 377 0.000 0.001 0.002 oGPS_NMEA(1) .GPS. 0 l 7 16 377 0.000 0.001 0.002 *bigben.cac.wash .GPS. 1 u 69 64 372 13.058 1.638 36.654 +clock.fmt.he.ne .CDMA. 1 u 15 64 373 32.641 1.938 28.828 -chronos6.es.net .CDMA. 1 u 9 64 377 92.321 10.473 2.335 -2001:4f8:2:d::1 129.6.15.29 2 u 31 64 377 35.545 9.912 43.519 -time0.apple.com 17.150.142.121 2 u 2 64 377 44.922 -1.275 26.193 > grateful for all the input and responses, this list is amazing as usual. > > On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris wrote: > > On 6 February 2014 12:30, Martin Hotze wrote: > > > >> > I'm trying to help a company I work for to pass an audit, and we've > >> > been told we need trusted NTP sources (RedHat doesn't cut it). > >> > Being located in Nigeria, Africa, > >> > > [...] > > > >> So build your own stratum 1 server (maybe a second one with DCF77 or > >> whatever you can use for redundancy), > >> > > > > I don't think DCF77 is going to reach Nigeria. > > > > Aled From jra at baylink.com Fri Feb 7 02:14:21 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 6 Feb 2014 21:14:21 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: Message-ID: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Milhollan" > Generally speaking, you'll need at least 3 sources if you want > stablity. My usual practice is to set up two in house servers, each of which talks to: time.windows.com time.apple.com and one of the NIST servers 0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org and each other. And then point everyone in house to both of them, assuming they accept multiple server names. But I am young, and not much travelled. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Fri Feb 7 02:24:42 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 6 Feb 2014 21:24:42 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: <52F3A409.9020800@cox.net> Message-ID: <6474841.7450.1391739882135.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Larry Sheldon" > After all these years I still can not get used to the non-standard NANOG > response to "reply". I wonder if there is a way for ne to fix that. Noo!!! Everybody!!! Don't reply to that!!! :-) Mailing lists aren't *supposed* to set Reply-To, Larry; your mail client is supposed to have a Reply To List command. Most "consumer" MUAs, of course, don't. Reply-All is a (usually) winked-upon subterfuge, or you can do like I do and just manually readjust the To header when you reply to the list. Just don't do what I do and accidentally set it to NANOG when you're replying to a different list's message. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From LarrySheldon at cox.net Fri Feb 7 02:42:07 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 06 Feb 2014 20:42:07 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: <52F447FF.6000009@cox.net> On 2/6/2014 8:24 PM, Jay Ashworth wrote: > Mailing lists aren't *supposed* to set Reply-To, Larry; your mail client is > supposed to have a Reply To List command. It does. And does not light up for most of the lists I am on (including one I "own"). I am apparently not bright enough to notice when it does light up. Most "consumer" MUAs, of course, > don't. > > Reply-All is a (usually) winked-upon subterfuge, or you can do like I > do and just manually readjust the To header when you reply to the list. The later apparently requiring even more brain power than I able to bring to bear on the problem. A FB community I am part of has several people in it that work in the same company--much flapping about a message sent to all--including people on continents who have no capability of being interested. Much don't send replies to "all"--sent to "all". > Just don't do what I do and accidentally set it to NANOG when you're > replying to a different list's message. :-) I was mildly chastised yesterday about a lengthy thread that I started about GPSs on MTRA when I could swear that I started on MTR. Old age has not been kind to me. > Cheers, > -- jra And I did consider sending this just to Jay, but decided the public humbling would be good. You need not bother everybody to tell me I was wrong. Again. It will get warm again someday. I'm pretty sure. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From frnkblk at iname.com Fri Feb 7 02:57:21 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 6 Feb 2014 20:57:21 -0600 Subject: Need trusted NTP Sources In-Reply-To: <20140206163413.GA21496@pob.ytti.fi> References: <66F884EE-08C3-4758-8160-AFEB37DA371C@deman.com> <20140206163413.GA21496@pob.ytti.fi> Message-ID: <008101cf23b0$527ddbf0$f77993d0$@iname.com> This doesn't address the full-mesh part, but this discussion suggests at least four servers, but better to have five. http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5 .3.3. Frank -----Original Message----- From: Saku Ytti [mailto:saku at ytti.fi] Sent: Thursday, February 06, 2014 10:34 AM To: nanog at nanog.org Subject: Re: Need trusted NTP Sources On (2014-02-06 07:24 -0800), Michael DeMan wrote: > A) Run a local set of NTP servers - these are your 'trusted' servers, under your control, properly managed/secured, fully meshed, etc. I'm not sure if full-mesh is best practice, the external clients should have full view of as close to source data as possible. If in full-mesh you're already masking the data with inaccuracy, giving the clients less information to make decision? We used to have full-mesh in our meinbergs, until from their recommendation we removed it completely. It makes sense to me, but I don't understand the issue deeply. -- ++ytti From faisal at snappytelecom.net Fri Feb 7 03:47:29 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 7 Feb 2014 03:47:29 +0000 (GMT) Subject: carrier comparison In-Reply-To: <52F40BF1.8030807@ramapo.edu> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F40BF1.8030807@ramapo.edu> Message-ID: <99972864.659915.1391744849579.JavaMail.root@snappytelecom.net> Based on your description, it sounds like the outage did not bring your BGP session down, as such you were connected and advertising to the broken Service Provider. e.g. Cogent typically does multi-hop bgp, as such if there a network outage past the BGP router, you will experience the situation you described. You might have to deploy some other means of (script ?) to bring your BGP session down from the 'broken' Service Provider. To the best of my knowledge, BGP does not have any mechanism to determine broken connectivity upstream past the router you are BGP session is up with. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Vlade Ristevski" > Cc: nanog at nanog.org > Sent: Thursday, February 6, 2014 5:25:53 PM > Subject: Re: carrier comparison > > B) We have our own AS and IP space. I advertise them to both Cogent and > our other ISP. I use the local preference attribute to share the load > for incoming traffic between both ISPs. In the last 5 outages over the > last few years, this has happened twice. I'm waiting on the RFO so I can > further investigate why this happened. I think someone mentioned this in > a post a few months ago too. > > It sucks for us, because we're a small school and don't have someone in > a NOC to monitor our networks 24x7. I literally had to get out of bed > and disable our BGP session with them for us to get through the outage. > I was getting around 90% packet loss from my home to our router. > > > On 2/6/2014 4:57 PM, Eric Flanery (eric) wrote: > > Vlade, > > > > When you say that "they still advertise your routes", do you mean: > > > > A: That you were having them originate your routes, and they failed to > > stop doing so when they had problems? Or... > > > > B: That routes you were originating continued to be propagated by > > them, even though your session with them was down? Or... > > > > C: Something else. > > > > I ask, as we are considering some cheap Cogent bandwidth in the > > not-too-distant future, to allow us to keep commit rates low on higher > > quality connections. 'A' wouldn't be a real problem, since we run our > > own AS and originate our own routes; 'B' could be potentially devastating. > > > > > > On Thu, Feb 6, 2014 at 8:04 AM, Vlade Ristevski > > wrote: > > > > We have had Cogent over Verizon's Fiber for more than a few years > > now. Cogent goes down once at year at minimum. They had 2 outages > > in a single day a couple days ago in Northern NJ. One in the AM > > "..caused by a power outage in a vendor data center where Cogent > > is collocated." They went on to have another outage at around 9:30 > > PM on the same day for which I'm still waiting for an RFO. During > > this outage, they still were advertising our BGP routes so we > > didn't fail over to our 2nd provider. I notice that happens alot > > with them. When they go down, they still advertise your routes. > > > > As far as price goes, for us Cogent is cheap but Lightpath is cheaper. > > > > Our college is kind of far from things so we don't have a lot of > > outside fiber coming. The last mile fiber for both of our > > connections are different from our Internet providers. I've never > > had a big issue with the two working with each other. The only > > issue we had is I suspected we weren't getting as much bandwidth > > as we paid for. They had to work out where the policer and/or > > bottle neck was. This is the only issue we had in 5 years with > > this set up and it got resolved. IME, when there is a full outage, > > it's always been clear who the responsible party is. > > > > > > > > > > > > > > On 2/6/2014 10:17 AM, Adam Greene wrote: > > > > Hi, > > > > > > We're a small ISP / datacenter with a Time Warner fiber-based > > DIA contract > > that is coming up for renewal. > > > > > > We're getting much better pricing offers from Cogent, and are > > finding out > > what Level 3 can do for us as well. Both providers will use > > Time Warner > > fiber for last mile. > > > > > > My questions are: > > > > - Will we be sacrificing quality if we spring for Cogent? > > (yesterday's Cogent/Verizon thread provided some cold chills > > for my spine) > > > > - Is there a risk with contracting a carrier that > > utilizes another > > carrier (such as Time Warner) for the last mile? (i.e. if > > there is a > > downtime situation, are we going to be caught in a web of > > confusion and > > finger-pointing that delays problem resolution)? > > > > - How are peoples' experiences with L3 vs TWC? > > > > > > Although I assume everyone on the list would be interested in > > what others > > have to say about these questions, out of respect for the > > carriers in > > question, I encourage you to email frank opinions off list. > > > > > > Or if there are third party tools or resources you know that I > > could consult > > to deduce the answers to these questions myself, they are most > > welcome. > > > > > > Thanks, > > > > Adam > > > > > > > > -- > Vlad > > From frnkblk at iname.com Fri Feb 7 05:00:13 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 6 Feb 2014 23:00:13 -0600 Subject: SIP on FTTH systems In-Reply-To: <201402061608.52822.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> <201402061608.52822.mark.tinka@seacom.mu> Message-ID: <00b301cf23c1$7c694dd0$753be970$@iname.com> And then you need MACFF to overcome the split-horizon to that customers in the same subnet can talk to each other. =) Frank -----Original Message----- From: Mark Tinka [mailto:mark.tinka at seacom.mu] Sent: Thursday, February 06, 2014 8:09 AM To: nanog at nanog.org Subject: Re: SIP on FTTH systems On Thursday, February 06, 2014 03:51:51 PM Anders L?winger wrote: > This is a deep hole, and basically does not work with > IPv6. > > You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 > inspection, RA guard and more. One VLAN per customer and > a separate multicast is much simpler. If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. I've also know Huawei OLT's support these split horizons too. > Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. Mark. From jra at baylink.com Fri Feb 7 05:59:24 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Feb 2014 00:59:24 -0500 (EST) Subject: SIP on FTTH systems In-Reply-To: <00b301cf23c1$7c694dd0$753be970$@iname.com> Message-ID: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Frank Bulk" > And then you need MACFF to overcome the split-horizon to that > customers in the same subnet can talk to each other. =) In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any "real" traffic there. Just attack traffic. Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From swmike at swm.pp.se Fri Feb 7 06:14:54 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Feb 2014 07:14:54 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 7 Feb 2014, Jay Ashworth wrote: > In my not-at-all humble opinion, in an eyeball network, you almost > *never* want to make it easier for houses to talk to one another > directly; there isn't any "real" traffic there. Just attack traffic. But creating a solution where you can talk to anyone else on the Internet but not the ones in your own neighborhood is broken, so it needs to be fixed. In IPv4 I've seen this solved with local-proxy-arp within the subnet, and for IPv6 it's easily solvable by not announcing an on-link network so they won't even try to communicate directly with each other but instead everything is routed via the ISP upstream router and then down again to the other customer CPE/computer. -- Mikael Abrahamsson email: swmike at swm.pp.se From jra at baylink.com Fri Feb 7 06:20:03 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Feb 2014 01:20:03 -0500 (EST) Subject: SIP on FTTH systems In-Reply-To: Message-ID: <10023760.7484.1391754003002.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mikael Abrahamsson" > On Fri, 7 Feb 2014, Jay Ashworth wrote: > > In my not-at-all humble opinion, in an eyeball network, you almost > > *never* want to make it easier for houses to talk to one another > > directly; there isn't any "real" traffic there. Just attack traffic. > > But creating a solution where you can talk to anyone else on the Internet > but not the ones in your own neighborhood is broken, so it needs to be > fixed. In IPv4 I've seen this solved with local-proxy-arp within the > subnet, and for IPv6 it's easily solvable by not announcing an on-link > network so they won't even try to communicate directly with each other but > instead everything is routed via the ISP upstream router and then down > again to the other customer CPE/computer. I did not show my work. I apologize. I will try again: If I am a commercial customer of an eyeball ISP like Road Runner: *I am entitled to expect that that ISP is technically capable of protecting me from possible attack traffic from that other customer*, who's outside my administrative span of control. If they can send me traffic directly across a local access subnet, that requires a much larger hammer than if such traffic must cross the edge concentrator first, the configuration I assert is a better choice. Does that help? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From swmike at swm.pp.se Fri Feb 7 07:11:38 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Feb 2014 08:11:38 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <10023760.7484.1391754003002.JavaMail.root@benjamin.baylink.com> References: <10023760.7484.1391754003002.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 7 Feb 2014, Jay Ashworth wrote: > If I am a commercial customer of an eyeball ISP like Road Runner: *I am > entitled to expect that that ISP is technically capable of protecting > me from possible attack traffic from that other customer*, who's outside > my administrative span of control. If they can send me traffic directly > across a local access subnet, that requires a much larger hammer than if > such traffic must cross the edge concentrator first, the configuration > I assert is a better choice. > > Does that help? Violent agreement. Customers should not talk L2 directly to each other using local switching, but they should be able to send IP packets to each other. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Fri Feb 7 08:18:00 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 7 Feb 2014 10:18:00 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <10023760.7484.1391754003002.JavaMail.root@benjamin.baylink.com> Message-ID: <201402071018.00407.mark.tinka@seacom.mu> On Friday, February 07, 2014 09:11:38 AM Mikael Abrahamsson wrote: > Violent agreement. Customers should not talk L2 directly > to each other using local switching, but they should be > able to send IP packets to each other. And in fairness, given the positive security benefits (barring extreme corner cases or hardware/software bugs), the otherwise sub-optimal tromboning between homes via the BNG is an acceptable compromise. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From olivier.benghozi at wifirst.fr Fri Feb 7 10:25:53 2014 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Fri, 7 Feb 2014 11:25:53 +0100 Subject: carrier comparison In-Reply-To: <99972864.659915.1391744849579.JavaMail.root@snappytelecom.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F40BF1.8030807@ramapo.edu> <99972864.659915.1391744849579.JavaMail.root@snappytelecom.net> Message-ID: <09A8BB2F-7CEE-4DF6-8A57-AD4C35ED8F50@wifirst.fr> Hi Faisal, > You might have to deploy some other means of (script ?) to bring your BGP session down from the 'broken' Service Provider. > > To the best of my knowledge, BGP does not have any mechanism to determine broken connectivity upstream past the router you are BGP session is up with. Well, technically there's BFD that might do the trick. But of course it won't be available; it's not usually, so specially with Cogent... :) But maybe its link was just overloaded in fact. -- Olivier From olivier.benghozi at wifirst.fr Fri Feb 7 10:27:58 2014 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Fri, 7 Feb 2014 11:27:58 +0100 Subject: carrier comparison In-Reply-To: <52F40BF1.8030807@ramapo.edu> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F40BF1.8030807@ramapo.edu> Message-ID: <8C46C395-5A65-4D12-9FCA-6D4F2E793C39@wifirst.fr> Hi Vlade, Well, if you are trying to balance the incoming traffic load with local-pref attribute, I can understand your disappointment :) Since it doesn't work at all this way: local-pref is local to an AS and deals with outgoing traffic only. > B) We have our own AS and IP space. I advertise them to both Cogent and our other ISP. I use the local preference attribute to share the load for incoming traffic between both ISPs. In the last 5 outages over the last few years, this has happened twice. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too. -- Olivier From saku at ytti.fi Fri Feb 7 11:35:25 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 7 Feb 2014 13:35:25 +0200 Subject: Need trusted NTP Sources In-Reply-To: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> Message-ID: <20140207113525.GA13919@pob.ytti.fi> On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > My usual practice is to set up two in house servers, each of which > talks to: > > And then point everyone in house to both of them, assuming they accept > multiple server names. Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them. -- ++ytti From mysidia at gmail.com Fri Feb 7 12:38:06 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 7 Feb 2014 06:38:06 -0600 Subject: Need trusted NTP Sources In-Reply-To: <20140207113525.GA13919@pob.ytti.fi> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> Message-ID: On Fri, Feb 7, 2014 at 5:35 AM, Saku Ytti wrote: > On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > > > My usual practice is to set up two in house servers, each of which > > talks to: > Two is worst possible amount of NTP servers to have. Either one fails and > your timing is wrong, because you cannot vote false ticker. And chance of > either of > two failing is higher than one specific of them. > +1 to having at least 3 NTP servers. Because complete outage is only one kind of failure. Don't forget poor performance due to high latency, or Server X emitting corrupted or inaccurate data -- -JH From frnkblk at iname.com Fri Feb 7 13:30:08 2014 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 7 Feb 2014 07:30:08 -0600 Subject: SIP on FTTH systems In-Reply-To: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> References: <00b301cf23c1$7c694dd0$753be970$@iname.com> <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> Message-ID: <00b401cf2408$b846cde0$28d469a0$@iname.com> Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. MACFF is supposed to solve that (we haven't turned it on, yet, because the vendor's implementation requires us to do some work on our provisioning system to make it easier). Frank -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Thursday, February 06, 2014 11:59 PM To: NANOG Subject: Re: SIP on FTTH systems ----- Original Message ----- > From: "Frank Bulk" > And then you need MACFF to overcome the split-horizon to that > customers in the same subnet can talk to each other. =) In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any "real" traffic there. Just attack traffic. Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From vristevs at ramapo.edu Fri Feb 7 14:19:15 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Fri, 07 Feb 2014 09:19:15 -0500 Subject: carrier comparison In-Reply-To: <8C46C395-5A65-4D12-9FCA-6D4F2E793C39@wifirst.fr> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F40BF1.8030807@ramapo.edu> <8C46C395-5A65-4D12-9FCA-6D4F2E793C39@wifirst.fr> Message-ID: <52F4EB63.7020806@ramapo.edu> I'm not setting it on my router locally but sending it over to Cogent as a community string per page 22 of their user guide. http://cogentco.com/files/docs/customer_service/guide/global_cogent_customer_user_guide.pdf They use it to manipulate how traffic gets back to me so that is incoming from my routers view. I also pad the AS for the networks that I prefer to come back through the other ISP.. On 2/7/2014 5:27 AM, Olivier Benghozi wrote: > Hi Vlade, > > Well, if you are trying to balance the incoming traffic load with local-pref attribute, I can understand your disappointment :) > Since it doesn't work at all this way: local-pref is local to an AS and deals with outgoing traffic only. > >> B) We have our own AS and IP space. I advertise them to both Cogent and our other ISP. I use the local preference attribute to share the load for incoming traffic between both ISPs. In the last 5 outages over the last few years, this has happened twice. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too. > -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 From faisal at snappytelecom.net Fri Feb 7 14:49:09 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 7 Feb 2014 14:49:09 +0000 (GMT) Subject: carrier comparison In-Reply-To: <09A8BB2F-7CEE-4DF6-8A57-AD4C35ED8F50@wifirst.fr> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F40BF1.8030807@ramapo.edu> <99972864.659915.1391744849579.JavaMail.root@snappytelecom.net> <09A8BB2F-7CEE-4DF6-8A57-AD4C35ED8F50@wifirst.fr> Message-ID: <693349979.661671.1391784549000.JavaMail.root@snappytelecom.net> Based on my understanding on BFD, it will not help you... BFD will detect the direct connected port being down quicker and force the BGP session down, (faster than the time BGP session timers take to determine something is broken) This is the common issue / challenge in how to determine up-stream path outage and then doing appropriate route engineering on an automatic basis. Maybe a SLA monitor type scripting/configuration be useful in your case. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Olivier Benghozi" > To: nanog at nanog.org > Sent: Friday, February 7, 2014 5:25:53 AM > Subject: Re: carrier comparison > > Hi Faisal, > > > You might have to deploy some other means of (script ?) to bring your BGP > > session down from the 'broken' Service Provider. > > > > To the best of my knowledge, BGP does not have any mechanism to determine > > broken connectivity upstream past the router you are BGP session is up > > with. > > Well, technically there's BFD that might do the trick. But of course it won't > be available; it's not usually, so specially with Cogent... :) > But maybe its link was just overloaded in fact. > > > -- > Olivier > > > From mark.tinka at seacom.mu Fri Feb 7 15:20:08 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 7 Feb 2014 17:20:08 +0200 Subject: SIP on FTTH systems In-Reply-To: <00b401cf2408$b846cde0$28d469a0$@iname.com> References: <00b301cf23c1$7c694dd0$753be970$@iname.com> <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <00b401cf2408$b846cde0$28d469a0$@iname.com> Message-ID: <201402071720.12145.mark.tinka@seacom.mu> On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: > Rather than assign residential and business customers > their own /30, to conserve space we give those customers > a /32 out of a /24. But when one of these static IP > customers wants to send email to another, or the > employee wants to VPN into work, they can't. This is akin to Private VLAN's where ports in a shared VLAN are assigned numbers from the same subnet, but they can only communicate via the BNG rather than directly at the bridge level. I prefer EVC Split Horizon to Private VLAN's, though. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Feb 7 15:21:46 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 7 Feb 2014 17:21:46 +0200 Subject: carrier comparison In-Reply-To: <693349979.661671.1391784549000.JavaMail.root@snappytelecom.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <09A8BB2F-7CEE-4DF6-8A57-AD4C35ED8F50@wifirst.fr> <693349979.661671.1391784549000.JavaMail.root@snappytelecom.net> Message-ID: <201402071721.47057.mark.tinka@seacom.mu> On Friday, February 07, 2014 04:49:09 PM Faisal Imtiaz wrote: > Based on my understanding on BFD, it will not help you... > BFD will detect the direct connected port being down > quicker and force the BGP session down, (faster than the > time BGP session timers take to determine something is > broken) You would also need your provider to support BFD (and by support I mostly mean willing to run, as modern gear today is technically capable). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From r.engehausen at gmail.com Fri Feb 7 15:23:22 2014 From: r.engehausen at gmail.com (Roy) Date: Fri, 07 Feb 2014 07:23:22 -0800 Subject: Need trusted NTP Sources In-Reply-To: <20140207113525.GA13919@pob.ytti.fi> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> Message-ID: <52F4FA6A.60807@gmail.com> On 2/7/2014 3:35 AM, Saku Ytti wrote: > On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > >> My usual practice is to set up two in house servers, each of which >> talks to: >> >> And then point everyone in house to both of them, assuming they accept >> multiple server names. > Two is worst possible amount of NTP servers to have. Either one fails and your > timing is wrong, because you cannot vote false ticker. And chance of either of > two failing is higher than one specific of them. > "A man with a watch knows what time it is. A man with two watches is never sure." From jra at baylink.com Fri Feb 7 15:41:44 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 07 Feb 2014 10:41:44 -0500 Subject: SIP on FTTH systems In-Reply-To: <201402071720.12145.mark.tinka@seacom.mu> References: <00b301cf23c1$7c694dd0$753be970$@iname.com> <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <00b401cf2408$b846cde0$28d469a0$@iname.com> <201402071720.12145.mark.tinka@seacom.mu> Message-ID: <3db10818-3072-482b-b619-5a884e10d538@email.android.com> I would assume that this whole mostly depends on which particular protocols and approaches your edge equipment can implement most efficiently - efficiently enough, that is, to be able to do it on every single port in a chassis. On February 7, 2014 10:20:08 AM EST, Mark Tinka wrote: >On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: > >> Rather than assign residential and business customers >> their own /30, to conserve space we give those customers >> a /32 out of a /24. But when one of these static IP >> customers wants to send email to another, or the >> employee wants to VPN into work, they can't. > >This is akin to Private VLAN's where ports in a shared VLAN >are assigned numbers from the same subnet, but they can only >communicate via the BNG rather than directly at the bridge >level. > >I prefer EVC Split Horizon to Private VLAN's, though. > >Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mark.tinka at seacom.mu Fri Feb 7 15:53:01 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 7 Feb 2014 17:53:01 +0200 Subject: SIP on FTTH systems In-Reply-To: <3db10818-3072-482b-b619-5a884e10d538@email.android.com> References: <00b301cf23c1$7c694dd0$753be970$@iname.com> <201402071720.12145.mark.tinka@seacom.mu> <3db10818-3072-482b-b619-5a884e10d538@email.android.com> Message-ID: <201402071753.01608.mark.tinka@seacom.mu> On Friday, February 07, 2014 05:41:44 PM Jay Ashworth wrote: > I would assume that this whole mostly depends on which > particular protocols and approaches your edge equipment > can implement most efficiently - efficiently enough, > that is, to be able to do it on every single port in a > chassis. Well, Split Horizon would be enabled on all the customer- facing ports. I am not aware of any protocol restrictions when running Split Horizon. I haven't run into any issues yet. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mhuff at ox.com Fri Feb 7 15:56:35 2014 From: mhuff at ox.com (Matthew Huff) Date: Fri, 7 Feb 2014 10:56:35 -0500 Subject: Need trusted NTP Sources In-Reply-To: <52F4FA6A.60807@gmail.com> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> <52F4FA6A.60807@gmail.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> Working in the financial world, the best practices is to have 4 ntp servers (if not using PTP). 1) You need 3 to determine the correct time (and detect bad tickers) 2) If you lose 1 of the 3 above, then you no longer can determine the correct time 3) Therefore with 4, you have redundancy. We have two Symmetricom Stratum 1 time servers synced via GPS with Rubidium oscillators, and two RHEL 6 servers running ntpd for our 4 servers. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations?? | Purchase, NY 10577 OTA Management LLC??? ???| Phone: 914-460-4039 -----Original Message----- From: Roy [mailto:r.engehausen at gmail.com] Sent: Friday, February 7, 2014 10:23 AM To: nanog at nanog.org Subject: Re: Need trusted NTP Sources On 2/7/2014 3:35 AM, Saku Ytti wrote: > On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > >> My usual practice is to set up two in house servers, each of which >> talks to: >> >> And then point everyone in house to both of them, assuming they >> accept multiple server names. > Two is worst possible amount of NTP servers to have. Either one fails > and your timing is wrong, because you cannot vote false ticker. And > chance of either of two failing is higher than one specific of them. > "A man with a watch knows what time it is. A man with two watches is never sure." -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 3095 bytes Desc: Matthew Huff.vcf URL: From cscora at apnic.net Fri Feb 7 18:12:00 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Feb 2014 04:12:00 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201402071812.s17IC0LT007874@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Feb, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 481577 Prefixes after maximum aggregation: 191369 Deaggregation factor: 2.52 Unique aggregates announced to Internet: 238471 Total ASes present in the Internet Routing Table: 46105 Prefixes per ASN: 10.45 Origin-only ASes present in the Internet Routing Table: 35582 Origin ASes announcing only one prefix: 16383 Transit ASes present in the Internet Routing Table: 6020 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1861 Unregistered ASNs in the Routing Table: 496 Number of 32-bit ASNs allocated by the RIRs: 5908 Number of 32-bit ASNs visible in the Routing Table: 4503 Prefixes from 32-bit ASNs in the Routing Table: 14343 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 12 Prefixes being announced from unallocated address space: 450 Number of addresses announced to Internet: 2666891428 Equivalent to 158 /8s, 245 /16s and 136 /24s Percentage of available address space announced: 72.0 Percentage of allocated address space announced: 72.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.7 Total number of prefixes smaller than registry allocations: 168062 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 114263 Total APNIC prefixes after maximum aggregation: 34392 APNIC Deaggregation factor: 3.32 Prefixes being announced from the APNIC address blocks: 116746 Unique aggregates announced from the APNIC address blocks: 48907 APNIC Region origin ASes present in the Internet Routing Table: 4881 APNIC Prefixes per ASN: 23.92 APNIC Region origin ASes announcing only one prefix: 1216 APNIC Region transit ASes present in the Internet Routing Table: 840 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 827 Number of APNIC addresses announced to Internet: 729428480 Equivalent to 43 /8s, 122 /16s and 50 /24s Percentage of available APNIC address space announced: 85.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 164783 Total ARIN prefixes after maximum aggregation: 82620 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 166088 Unique aggregates announced from the ARIN address blocks: 77127 ARIN Region origin ASes present in the Internet Routing Table: 16132 ARIN Prefixes per ASN: 10.30 ARIN Region origin ASes announcing only one prefix: 6097 ARIN Region transit ASes present in the Internet Routing Table: 1679 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 62 Number of ARIN addresses announced to Internet: 1077581312 Equivalent to 64 /8s, 58 /16s and 150 /24s Percentage of available ARIN address space announced: 57.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 121619 Total RIPE prefixes after maximum aggregation: 61723 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 125577 Unique aggregates announced from the RIPE address blocks: 80205 RIPE Region origin ASes present in the Internet Routing Table: 17634 RIPE Prefixes per ASN: 7.12 RIPE Region origin ASes announcing only one prefix: 8323 RIPE Region transit ASes present in the Internet Routing Table: 2867 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2613 Number of RIPE addresses announced to Internet: 656485508 Equivalent to 39 /8s, 33 /16s and 44 /24s Percentage of available RIPE address space announced: 95.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 54351 Total LACNIC prefixes after maximum aggregation: 9972 LACNIC Deaggregation factor: 5.45 Prefixes being announced from the LACNIC address blocks: 59905 Unique aggregates announced from the LACNIC address blocks: 27711 LACNIC Region origin ASes present in the Internet Routing Table: 2065 LACNIC Prefixes per ASN: 29.01 LACNIC Region origin ASes announcing only one prefix: 548 LACNIC Region transit ASes present in the Internet Routing Table: 408 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 992 Number of LACNIC addresses announced to Internet: 150415648 Equivalent to 8 /8s, 247 /16s and 41 /24s Percentage of available LACNIC address space announced: 89.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12102 Total AfriNIC prefixes after maximum aggregation: 2624 AfriNIC Deaggregation factor: 4.61 Prefixes being announced from the AfriNIC address blocks: 12811 Unique aggregates announced from the AfriNIC address blocks: 4145 AfriNIC Region origin ASes present in the Internet Routing Table: 697 AfriNIC Prefixes per ASN: 18.38 AfriNIC Region origin ASes announcing only one prefix: 199 AfriNIC Region transit ASes present in the Internet Routing Table: 148 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 9 Number of AfriNIC addresses announced to Internet: 50426112 Equivalent to 3 /8s, 1 /16s and 113 /24s Percentage of available AfriNIC address space announced: 50.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2934 11562 880 Korea Telecom 17974 2748 902 88 PT Telekomunikasi Indonesia 7545 2176 320 117 TPG Telecom Limited 4755 1823 392 194 TATA Communications formerly 9829 1585 1283 39 National Internet Backbone 9583 1297 101 535 Sify Limited 7552 1236 1082 13 Viettel Corporation 9498 1218 309 68 BHARTI Airtel Ltd. 4808 1168 2117 354 CNCGROUP IP network China169 24560 1106 376 172 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3027 3688 53 BellSouth.net Inc. 22773 2326 2938 139 Cox Communications Inc. 1785 2158 690 128 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1684 1665 576 Charter Communications 4323 1623 1090 411 tw telecom holdings, inc. 701 1495 11189 765 MCI Communications Services, 30036 1370 296 570 Mediacom Communications Corp 6983 1299 772 582 ITC^Deltacom 7018 1286 18003 841 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1778 544 16 OJSC "Vimpelcom" 34984 1387 243 227 TELLCOM ILETISIM HIZMETLERI A 20940 1221 453 921 Akamai International B.V. 13188 1045 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 6849 859 362 37 JSC "Ukrtelecom" 8551 827 370 41 Bezeq International-Ltd 6830 771 2327 424 Liberty Global Operations B.V 12479 704 797 55 France Telecom Espana SA 35228 553 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3388 1881 82 NET Servi?os de Comunica??o S 10620 2722 438 213 Telmex Colombia S.A. 18881 1868 908 20 Global Village Telecom 7303 1745 1165 220 Telecom Argentina S.A. 8151 1377 2888 423 Uninet S.A. de C.V. 6503 930 434 61 Axtel, S.A.B. de C.V. 11830 869 364 15 Instituto Costarricense de El 7738 847 1626 39 Telemar Norte Leste S.A. 27947 830 93 94 Telconet S.A 6147 768 373 27 Telefonica del Peru S.A.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1810 240 6 Sudanese Mobile Telephone (ZA 24863 917 380 28 Link Egypt (Link.NET) 6713 602 685 28 Office National des Postes et 8452 483 956 9 TE-AS 24835 298 144 9 Vodafone Data 36992 271 783 24 ETISALAT MISR 3741 247 921 208 Internet Solutions 29571 245 21 16 Cote d'Ivoire Telecom 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3388 1881 82 NET Servi?os de Comunica??o S 6389 3027 3688 53 BellSouth.net Inc. 4766 2934 11562 880 Korea Telecom 17974 2748 902 88 PT Telekomunikasi Indonesia 10620 2722 438 213 Telmex Colombia S.A. 22773 2326 2938 139 Cox Communications Inc. 7545 2176 320 117 TPG Telecom Limited 1785 2158 690 128 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1868 908 20 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3027 2974 BellSouth.net Inc. 17974 2748 2660 PT Telekomunikasi Indonesia 10620 2722 2509 Telmex Colombia S.A. 22773 2326 2187 Cox Communications Inc. 7545 2176 2059 TPG Telecom Limited 4766 2934 2054 Korea Telecom 1785 2158 2030 PaeTec Communications, Inc. 18566 2048 1870 MegaPath Corporation 18881 1868 1848 Global Village Telecom 36998 1810 1804 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.88.0.0/16 6697 Republican Unitary Telecommun 100.89.0.0/16 6697 Republican Unitary Telecommun 100.90.0.0/16 6697 Republican Unitary Telecommun 100.91.0.0/16 6697 Republican Unitary Telecommun 100.92.0.0/16 6697 Republican Unitary Telecommun 100.93.0.0/16 6697 Republican Unitary Telecommun 100.94.0.0/16 6697 Republican Unitary Telecommun 100.95.0.0/16 6697 Republican Unitary Telecommun 100.104.0.0/13 6697 Republican Unitary Telecommun 100.112.0.0/13 6697 Republican Unitary Telecommun Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 Suburban Telecom 41.73.2.0/24 37004 Suburban Telecom 41.73.3.0/24 37004 Suburban Telecom 41.73.4.0/24 37004 Suburban Telecom 41.73.7.0/24 37004 Suburban Telecom 41.73.8.0/24 37004 Suburban Telecom 41.73.10.0/24 37004 Suburban Telecom 41.73.11.0/24 37004 Suburban Telecom 41.73.12.0/24 37004 Suburban Telecom Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:30 /11:92 /12:253 /13:477 /14:952 /15:1656 /16:12880 /17:6822 /18:11519 /19:23772 /20:33466 /21:36102 /22:51389 /23:44752 /24:255205 /25:778 /26:933 /27:422 /28:12 /29:17 /30:8 /31:0 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 36998 1771 1810 Sudanese Mobile Telephone (ZA 6389 1697 3027 BellSouth.net Inc. 22773 1570 2326 Cox Communications Inc. 8402 1456 1778 OJSC "Vimpelcom" 30036 1209 1370 Mediacom Communications Corp 11492 1162 1200 CABLE ONE, INC. 1785 1161 2158 PaeTec Communications, Inc. 6983 1039 1299 ITC^Deltacom 22561 980 1264 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:950 2:776 3:3 4:16 5:897 6:21 8:658 12:1858 13:3 14:940 15:9 16:3 17:23 18:19 20:36 23:669 24:1725 27:1737 31:1561 32:44 33:2 34:5 36:121 37:1898 38:923 39:4 40:191 41:3287 42:244 44:17 46:2170 47:12 49:664 50:895 52:12 54:45 55:3 57:26 58:1143 59:590 60:369 61:1511 62:1235 63:1959 64:4376 65:2248 66:4151 67:2031 68:1031 69:3301 70:867 71:471 72:2011 74:2643 75:313 76:308 77:1184 78:1035 79:693 80:1324 81:1102 82:672 83:740 84:721 85:1263 86:475 87:1032 88:523 89:1760 90:152 91:5731 92:672 93:1651 94:2074 95:1460 96:533 97:351 98:1072 99:39 100:32 101:768 103:4122 105:536 106:143 107:433 108:539 109:2090 110:967 111:1239 112:610 113:824 114:773 115:1084 116:1026 117:841 118:1244 119:1305 120:327 121:789 122:1911 123:1260 124:1384 125:1445 128:642 129:241 130:362 131:659 132:356 133:157 134:318 135:74 136:281 137:260 138:349 139:153 140:203 141:357 142:552 143:435 144:498 145:99 146:598 147:412 148:789 149:344 150:151 151:567 152:421 153:207 154:80 155:522 156:317 157:368 158:293 159:836 160:356 161:466 162:1109 163:217 164:672 165:597 166:278 167:592 168:1046 169:124 170:1176 171:196 172:14 173:1603 174:683 175:572 176:1422 177:2714 178:1950 179:440 180:1620 181:994 182:1434 183:494 184:658 185:1248 186:2760 187:1439 188:2004 189:1278 190:7435 191:44 192:7092 193:5449 194:4005 195:3368 196:1369 197:1086 198:4884 199:5551 200:6086 201:2551 202:9038 203:8896 204:4483 205:2644 206:2924 207:2829 208:3970 209:3653 210:3098 211:1639 212:2228 213:2013 214:870 215:84 216:5507 217:1695 218:566 219:324 220:1272 221:593 222:335 223:591 End of report From jared at puck.nether.net Fri Feb 7 18:14:09 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 7 Feb 2014 13:14:09 -0500 Subject: Need trusted NTP Sources In-Reply-To: <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> <52F4FA6A.60807@gmail.com> <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> Message-ID: <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> On Feb 7, 2014, at 10:56 AM, Matthew Huff wrote: > Working in the financial world, the best practices is to have 4 ntp servers (if not using PTP). > > 1) You need 3 to determine the correct time (and detect bad tickers) > 2) If you lose 1 of the 3 above, then you no longer can determine the correct time > 3) Therefore with 4, you have redundancy. > > We have two Symmetricom Stratum 1 time servers synced via GPS with Rubidium oscillators, and two RHEL 6 servers running ntpd for our 4 servers. Having a number of NTP servers will help you detect false tickers which may be critical. If you want something that is "cheap" as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. http://www.netburnerstore.com/product_p/pk70ex-ntp.htm You can get the whole thing going quickly. Majdi has also had good luck with this unit (perhaps he wants to chime-in, heh pun unintended) regarding a few other devices. If you ask politely off-list, I will point you at where one of these is that you can talk to (in Dallas at the Infomart for your low-latency config). - Jared From Jason_Livingood at cable.comcast.com Fri Feb 7 19:26:19 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 7 Feb 2014 19:26:19 +0000 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <20140206001143.8FA17E78FE4@rock.dv.isc.org> Message-ID: On 2/5/14, 7:11 PM, "Mark Andrews" wrote: >Well when industries don't self regulate governments step in. This >industry is demonstratably incapble of regulating itself in this >area despite lots of evidence of the problems being caused for lots >of years. Which industry is that? App providers that have not implemented? Hosting providers that have not? Transit providers that have not? Access network ISPs that have not? Large enterprises and education networks that have not? ;-) I still prefer a list of specific networks that need to pay attention to improving anti-spoofing since otherwise I think most of us are in violent agreement on the need. >This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 >years. Everybody else is having to deal the problems caused by >these bad actors. > >Hell, I suspect you could send the directors to gaol or make them >pay a heavy fine today by properly examining the existing laws. A new >law would just make the problem more explicit. In the U.S. one of the FCC Communications Security, Reliability, and Interoperability Council (CSRIC) working groups is focused on this issue. I do not know what is happening in other jurisdictions. Jason From LarrySheldon at cox.net Fri Feb 7 19:30:09 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 07 Feb 2014 13:30:09 -0600 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: References: Message-ID: <52F53441.3020205@cox.net> On 2/7/2014 1:26 PM, Livingood, Jason wrote: > I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From Jason_Livingood at cable.comcast.com Fri Feb 7 19:44:48 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 7 Feb 2014 19:44:48 +0000 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: <52F53441.3020205@cox.net> Message-ID: On 2/7/14, 2:30 PM, "Larry Sheldon" wrote: >On 2/7/2014 1:26 PM, Livingood, Jason wrote: >> I do not know what is happening in other jurisdictions. > >I find that seriously scary, if wide-spread. Sorry - too many country-by-country regulators to keep track of? From LarrySheldon at cox.net Fri Feb 7 19:47:43 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 07 Feb 2014 13:47:43 -0600 Subject: Why won't providers source-filter attacks? Simple. In-Reply-To: References: Message-ID: <52F5385F.5010304@cox.net> On 2/7/2014 1:44 PM, Livingood, Jason wrote: > On 2/7/14, 2:30 PM, "Larry Sheldon" wrote: > > >> On 2/7/2014 1:26 PM, Livingood, Jason wrote: >>> I do not know what is happening in other jurisdictions. >> >> I find that seriously scary, if wide-spread. > > Sorry - too many country-by-country regulators to keep track of? Each and every and any one of which can put you and me out of business. Or worse. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From bryan at digitalocean.com Fri Feb 7 20:03:27 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 7 Feb 2014 15:03:27 -0500 Subject: carrier comparison In-Reply-To: References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> Message-ID: Did you verify your problem was announcements on the other side of the outage? This sounds to me like you are using a bgp announced default route from cogent which is always sent. I think the problem was you were sending traffic out a path that was broken. Since you mentioned your outbound balancing this would explain some packet loss and not 100% loss. Bryan Socha Network Engineer DigitalOcean From alby.williams at verizon.com Fri Feb 7 20:32:22 2014 From: alby.williams at verizon.com (Anthony Williams) Date: Fri, 07 Feb 2014 15:32:22 -0500 Subject: Need trusted NTP Sources In-Reply-To: <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> <52F4FA6A.60807@gmail.com> <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> Message-ID: <52F542D6.50104@one.verizon.com> With a quick and easy mod, another option for $35 is a Sure Electronics GPS board. GPS: http://www.sureelectronics.net/goods.php?id=99 Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm -Alby On 2/7/2014 1:14 PM, Jared Mauch wrote: > Having a number of NTP servers will help you detect false tickers which may be critical. > > If you want something that is "cheap" as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. From jcurran at arin.net Fri Feb 7 20:37:49 2014 From: jcurran at arin.net (John Curran) Date: Fri, 7 Feb 2014 20:37:49 +0000 Subject: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.) In-Reply-To: References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> Message-ID: On Feb 5, 2014, at 2:12 AM, Jimmy Hess wrote: >> On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: >>> Now if we could get equipement vendors to stop shipping models >>> without the necessary support it would help but that also may require >>> government intervention. >>> ... > > A good start would be to get BCP38 revised to router the Host > requirements RFCs, to indicate that ingress filtering should be > considered mandatory on site-facing interfaces. > ... It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. > If the standards documents still just call it a best practice.... what > hope is there of having governments require it of the service providers > that their networks are connected to, anyways? There is a significant difference between a "best current practice" (BCP) document from the IETF (a technical standards body) versus one which actually reflects the well-considered best practices of a large network operator forum. The latter would be of some interest to governments (and groups of governments) when they ask for any options that might help with their growing spam and DDoS concerns... FYI, /John From vristevs at ramapo.edu Fri Feb 7 20:57:00 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Fri, 07 Feb 2014 15:57:00 -0500 Subject: carrier comparison In-Reply-To: References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> Message-ID: <52F5489C.9090409@ramapo.edu> We don't get a default route from them. At the time of the outage my bgp session was up and I had a full routing table from them. I didn't have much time to troubleshoot it in that state since we were down so I had to disable the session ASAP. Once the RFO comes in, I'll be asking a lot more questions about it. My only experience with BGP is as a customer so I'm not too familiar with the intricacies on the provider side. We had an outage in the AM the same day and we failed over just fine. I'm very curious why the same didn't happen in the evening. On 2/7/2014 3:03 PM, Bryan Socha wrote: > Did you verify your problem was announcements on the other side of the > outage? This sounds to me like you are using a bgp announced default > route from cogent which is always sent. I think the problem was you > were sending traffic out a path that was broken. Since you mentioned > your outbound balancing this would explain some packet loss and not > 100% loss. > > > Bryan Socha > Network Engineer > DigitalOcean -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 From rdobbins at arbor.net Fri Feb 7 21:07:17 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 7 Feb 2014 21:07:17 +0000 Subject: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.) In-Reply-To: References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> Message-ID: <059837B2-A908-43DF-BC23-E6612EAF90C2@arbor.net> On Feb 8, 2014, at 3:37 AM, John Curran wrote: > It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. Many already do - including operators of very large networks. There are operational, vendor, and topological considerations which mean that it's achieved utilizing various mechanisms in different scenarios. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From cgrundemann at gmail.com Fri Feb 7 21:25:01 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 7 Feb 2014 14:25:01 -0700 Subject: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.) In-Reply-To: <059837B2-A908-43DF-BC23-E6612EAF90C2@arbor.net> References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <059837B2-A908-43DF-BC23-E6612EAF90C2@arbor.net> Message-ID: On Fri, Feb 7, 2014 at 2:07 PM, Dobbins, Roland wrote: > > On Feb 8, 2014, at 3:37 AM, John Curran wrote: > > > It's also true that if a sizable group of network operators were to > actually deploy source address validation (thus proving that it really is a > reasonable approach and doesn't carry too much operational or vendor > implications), then it would be quite reasonable for those operators to > bring the results to NANOG and get it recognized as a best current > operating practice for networks of similar design/purpose. > > Many already do - including operators of very large networks. There are > operational, vendor, and topological considerations which mean that it's > achieved utilizing various mechanisms in different scenarios. > Documenting those various mechanisms which are actually utilized is the key here. =) $0.02 ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From rdobbins at arbor.net Fri Feb 7 21:37:27 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 7 Feb 2014 21:37:27 +0000 Subject: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.) In-Reply-To: References: <977303.7242.1391542533531.JavaMail.root@benjamin.baylink.com> <20140204220039.A77B0E52DCC@rock.dv.isc.org> <52F17931.40604@alter3d.ca> <20140205011854.7C1B8E548F3@rock.dv.isc.org> <16144.1391572892@turing-police.cc.vt.edu> <059837B2-A908-43DF-BC23-E6612EAF90C2@arbor.net> Message-ID: <7FFBD228-9827-4B84-8EBD-889B0EE82700@arbor.net> On Feb 8, 2014, at 4:25 AM, Chris Grundemann wrote: > Documenting those various mechanisms which are actually utilized is the key here. =) Yes, as well as the various limitations and caveats, like the wholesale/retail issue (i.e., customers of my customer). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From faisal at snappytelecom.net Fri Feb 7 21:42:48 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 7 Feb 2014 21:42:48 +0000 (GMT) Subject: carrier comparison In-Reply-To: <52F5489C.9090409@ramapo.edu> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F5489C.9090409@ramapo.edu> Message-ID: <1071594870.664942.1391809368351.JavaMail.root@snappytelecom.net> This is exactly what I thought had happened....The outage that affected you was one our two routers up-stream from your connection to that provider. I am not trying to defend any Carrier, but there is no 'routing protocol' what will react to this kind of an issue..... Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Vlade Ristevski" > Cc: "nanog list" > Sent: Friday, February 7, 2014 3:57:00 PM > Subject: Re: carrier comparison > > We don't get a default route from them. At the time of the outage my bgp > session was up and I had a full routing table from them. I didn't have > much time to troubleshoot it in that state since we were down so I had > to disable the session ASAP. Once the RFO comes in, I'll be asking a lot > more questions about it. My only experience with BGP is as a customer so > I'm not too familiar with the intricacies on the provider side. We had > an outage in the AM the same day and we failed over just fine. I'm very > curious why the same didn't happen in the evening. > > > > On 2/7/2014 3:03 PM, Bryan Socha wrote: > > Did you verify your problem was announcements on the other side of the > > outage? This sounds to me like you are using a bgp announced default > > route from cogent which is always sent. I think the problem was you > > were sending traffic out a path that was broken. Since you mentioned > > your outbound balancing this would explain some packet loss and not > > 100% loss. > > > > > > Bryan Socha > > Network Engineer > > DigitalOcean > > -- > Vlade Ristevski > Network Manager > IT Services > Ramapo College > (201)-684-6854 > > > From cidr-report at potaroo.net Fri Feb 7 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Feb 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201402072200.s17M01dY042730@wattle.apnic.net> This report has been generated at Fri Feb 7 21:13:36 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 31-01-14 491578 275802 01-02-14 491660 275860 02-02-14 491613 276047 03-02-14 491838 275998 04-02-14 491832 275909 05-02-14 491982 276297 06-02-14 492203 276288 07-02-14 492404 276405 AS Summary 46262 Number of ASes in routing system 18980 Number of ASes announcing only one prefix 4471 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 119428352 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 07Feb14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 492602 276419 216183 43.9% All ASes AS28573 3408 84 3324 97.5% NET Servi?os de Comunica??o S.A. AS6389 3027 56 2971 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 4471 1706 2765 61.8% WINDSTREAM - Windstream Communications Inc AS17974 2747 177 2570 93.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 2329 228 2101 90.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2934 889 2045 69.7% KIXS-AS-KR Korea Telecom AS18881 1868 35 1833 98.1% Global Village Telecom AS1785 2158 406 1752 81.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS36998 1810 97 1713 94.6% SDN-MOBITEL AS10620 2722 1175 1547 56.8% Telmex Colombia S.A. AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2929 1514 1415 48.3% TWTC - tw telecom holdings, inc. AS7303 1745 415 1330 76.2% Telecom Argentina S.A. AS4755 1823 588 1235 67.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1261 157 1104 87.5% VIETEL-AS-AP Viettel Corporation AS7545 2178 1120 1058 48.6% TPG-INTERNET-AP TPG Telecom Limited AS22561 1264 227 1037 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1592 650 942 59.2% BSNL-NIB National Internet Backbone AS18101 993 187 806 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1168 393 775 66.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS35908 869 107 762 87.7% VPLSNET - Krypt Technologies AS24560 1106 372 734 66.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS701 1495 765 730 48.8% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1386 665 721 52.0% Uninet S.A. de C.V. AS6983 1299 582 717 55.2% ITCDELTA - ITC^Deltacom AS7738 847 148 699 82.5% Telemar Norte Leste S.A. AS4788 937 241 696 74.3% TMNET-AS-AP TM Net, Internet Service Provider AS855 749 57 692 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 1027 371 656 63.9% SEEDNET Digital United Inc. AS6147 768 113 655 85.3% Telefonica del Peru S.A.A. Total 54957 14090 40867 74.4% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.3.0/24 AS37004 41.73.4.0/24 AS37004 41.73.7.0/24 AS37004 41.73.8.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.17.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS30097 NUWAVE - NuWave 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.220.176.0/24 AS16265 LEASEWEB LeaseWeb B.V. 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 93.190.10.0/24 AS47254 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK 107.181.80.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.81.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.82.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.83.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.84.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.85.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.86.0/24 AS55106 DATACATEASN1 - Datacate Inc. 107.181.87.0/24 AS55106 DATACATEASN1 - Datacate Inc. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 151.216.128.0/17 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.88.0.0/24 AS29571 CITelecom-AS 172.89.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 191.6.176.0/20 AS26242 Link10 Telecom 191.6.192.0/19 AS28299 IPV6 Internet Ltda 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.26.0.0/24 AS34028 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.38.144.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.52.0/23 AS16276 OVH OVH Systems 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.121.0/24 AS9143 ZIGGO Ziggo B.V. 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.28.168.0/23 AS8655 195.64.128.0/23 AS8751 MEDIASAT Media Sat SRL 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 7 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Feb 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201402072200.s17M02Y9042750@wattle.apnic.net> BGP Update Report Interval: 30-Jan-14 -to- 06-Feb-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4800 83579 3.9% 363.4 -- LINTASARTA-AS-AP Network Access Provider and Internet Service Provider 2 - AS9829 63814 3.0% 64.7 -- BSNL-NIB National Internet Backbone 3 - AS35181 44454 2.1% 3704.5 -- PWC Autonomous System Number for Public WareHouse Company 4 - AS8402 40917 1.9% 21.4 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS31148 25755 1.2% 25.4 -- FREENET-AS Freenet Ltd. 6 - AS27738 24132 1.1% 41.8 -- Ecuadortelecom S.A. 7 - AS10620 22841 1.1% 17.4 -- Telmex Colombia S.A. 8 - AS13118 20696 1.0% 481.3 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS41691 20336 0.9% 726.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - AS60349 18872 0.9% 299.6 -- PBL-KIEV-AS Partners. Business & Law Ltd. 11 - AS4775 18843 0.9% 254.6 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS8151 17333 0.8% 17.0 -- Uninet S.A. de C.V. 13 - AS59217 15379 0.7% 15379.0 -- AZONNELIMITED-AS-AP Azonne Limited 14 - AS647 13326 0.6% 115.9 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 15 - AS28573 13323 0.6% 11.1 -- NET Servi?os de Comunica??o S.A. 16 - AS50710 12631 0.6% 60.4 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 17 - AS11976 12505 0.6% 211.9 -- FIDN - Fidelity Communication International Inc. 18 - AS11139 12429 0.6% 30.2 -- CWRIN CW BARBADOS 19 - AS18747 11627 0.5% 37.4 -- 20 - AS6713 10822 0.5% 23.5 -- IAM-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 15379 0.7% 15379.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS19406 3793 0.2% 3793.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS35181 44454 2.1% 3704.5 -- PWC Autonomous System Number for Public WareHouse Company 4 - AS54465 6971 0.3% 2323.7 -- QPM-AS-1 - QuickPlay Media Inc. 5 - AS12922 1952 0.1% 1952.0 -- MULTITRADE-AS CEDACRI S.P.A. 6 - AS62431 1863 0.1% 1863.0 -- NCSC-IE-AS National Cyber Security Centre 7 - AS6629 9039 0.4% 1807.8 -- NOAA-AS - NOAA 8 - AS32244 5133 0.2% 1711.0 -- LIQUID-WEB-INC - Liquid Web, Inc. 9 - AS14287 9914 0.5% 1652.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 10 - AS16561 3247 0.1% 1623.5 -- ARIBANETWORK Ariba Inc. Autonomous System 11 - AS30437 4316 0.2% 1438.7 -- GE-MS003 - General Electric Company 12 - AS44153 1146 0.1% 1146.0 -- SHTE Shirak Technologies LLC 13 - AS57364 1089 0.1% 1089.0 -- KMARUDA-AS OJSC Kombinat KMAruda 14 - AS7202 1977 0.1% 988.5 -- FAMU - Florida A & M University 15 - AS24959 877 0.0% 877.0 -- LINJEGODS-AS Schenker AS 16 - AS52571 3499 0.2% 874.8 -- G2G COM PROD ELETRO E SERV LTDA 17 - AS51075 843 0.0% 843.0 -- WOLFF-PL WYDAWNICTWO MULTIMEDIALNE KOWALEWSKI I WOLFF SPOLKA CYWILNA PIOTR GLADKI KRZYSZTOF KOWALEWSKI MACIEJ MANSKI 18 - AS41691 20336 0.9% 726.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 19 - AS23019 662 0.0% 662.0 -- BGP1-BOH - BANK OF HAWAII 20 - AS37546 650 0.0% 650.0 -- MIA-TELECOMs TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.239.28.0/24 22575 1.0% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 2 - 85.239.24.0/24 21832 0.9% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 3 - 109.161.64.0/20 20484 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 4 - 103.243.164.0/22 15379 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 5 - 89.221.206.0/24 11680 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 6 - 216.109.107.0/24 10451 0.5% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 8 - 222.127.0.0/24 9195 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 192.58.232.0/24 9031 0.4% AS6629 -- NOAA-AS - NOAA 10 - 85.249.160.0/20 8297 0.4% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 11 - 205.247.12.0/24 7715 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 12 - 206.152.15.0/24 6951 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 13 - 67.210.190.0/23 6879 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 14 - 200.23.126.0/24 5809 0.2% AS8151 -- Uninet S.A. de C.V. 15 - 67.210.188.0/23 5415 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 16 - 199.187.118.0/24 4529 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 17 - 165.156.25.0/24 4311 0.2% AS30437 -- GE-MS003 - General Electric Company 18 - 69.38.178.0/24 3793 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 19 - 84.205.66.0/24 2858 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC) 20 - 2.93.235.0/24 2724 0.1% AS8402 -- CORBINA-AS OJSC "Vimpelcom" Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From tglassey at earthlink.net Fri Feb 7 23:38:51 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Fri, 07 Feb 2014 15:38:51 -0800 Subject: You need a VLAN to the foot of NIST ITS services - no problem - we got you covered. Re: Need trusted NTP Sources In-Reply-To: <52F542D6.50104@one.verizon.com> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> <52F4FA6A.60807@gmail.com> <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> <52F542D6.50104@one.verizon.com> Message-ID: <52F56E8B.4090901@earthlink.net> Raspberry Pi ------------------- This unfortunately doest give you trusted time. It gives you David's Raspberry Pi with an Adafruit Ultimate GPS breakout board which is a waste of time if you need an evidence grade of time service. It also means you assemble it and run it yourself. If you need access to NTP - we can handle that ------------------------------------------------------------------- As to how to get NTP into your networks - why screw around??? What do you need - your own VLAN into the back of the switch hosting the NIST ITS server... yeah no problem. Go to the source and join USTiming.ORG and use our landing switch to cross connect your network into a VLAN type management network bringing NIST ITS services to the perimeter of your network - poof - no DDoS, and hey you get to work with us to expand the availability of the services across the US so its a win-win. We have them spread out through the US under USTiming and are looking for more sites that are telco hotels in particular - so if you have space and want to host is in a balance-of-trade type deal let us know. Todd On 2/7/2014 12:32 PM, Anthony Williams wrote: > > With a quick and easy mod, another option for $35 is a Sure Electronics > GPS board. > > GPS: http://www.sureelectronics.net/goods.php?id=99 > > Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm > > -Alby > > > On 2/7/2014 1:14 PM, Jared Mauch wrote: >> Having a number of NTP servers will help you detect false tickers which may be critical. >> >> If you want something that is "cheap" as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. > > > -- ------------- Personal Email - Disclaimers Apply From jason at lixfeld.ca Sat Feb 8 00:01:31 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 7 Feb 2014 19:01:31 -0500 Subject: Cogeco in the house? Message-ID: If someone from Cogeco could ping me, I'd like to have a chat about something odd and intermittent: It works: BlackBox:~ jlixfeld$ mtr -c 1 -rw 162.243.142.155 Start: Fri Feb 7 18:46:06 2014 HOST: BlackBox.local Loss% Drop Rcv Snt Last Best Avg 1.|-- 192.168.69.1 0.0% 0 1 1 4.0 4.0 4.0 2.|-- 96-45-207-217.beanfield.net 0.0% 0 1 1 9.3 9.3 9.3 3.|-- gi0-1-0-2.bfr01.77mowatav01.yyz.beanfield.com 0.0% 0 1 1 9.9 9.9 9.9 4.|-- be2.bfr01.60hudsonst01.jfk.beanfield.com 0.0% 0 1 1 20.8 20.8 20.8 5.|-- nyk-b3-link.telia.net 0.0% 0 1 1 19.3 19.3 19.3 6.|-- nyk-bb1-link.telia.net 0.0% 0 1 1 19.5 19.5 19.5 7.|-- sjo-bb1-link.telia.net 0.0% 0 1 1 92.5 92.5 92.5 8.|-- digitalocean-ic-302451-sjo-bb1.c.telia.net 0.0% 0 1 1 93.9 93.9 93.9 9.|-- 198.199.99.238 0.0% 0 1 1 94.6 94.6 94.6 10.|-- streetscapeplus.com 0.0% 0 1 1 94.2 94.2 94.2 BlackBox:~ jlixfeld$ Now it doesn't: BlackBox:~ jlixfeld$ mtr -c 1 -r 162.243.142.155 Start: Fri Feb 7 18:42:54 2014 HOST: BlackBox.local Loss% Drop Rcv Snt Last Best Avg 1.|-- 192.168.69.1 0.0% 0 1 1 4.2 4.2 4.2 2.|-- 96-45-207-217.beanfield.n 0.0% 0 1 1 9.0 9.0 9.0 3.|-- gi0-1-0-2.bfr01.77mowatav 0.0% 0 1 1 9.8 9.8 9.8 4.|-- te0-0-0-1.bfr01.151fronts 0.0% 0 1 1 9.5 9.5 9.5 5.|-- gw-mto.torontointernetxch 0.0% 0 1 1 9.0 9.0 9.0 6.|-- tge-1-1.ar1.mtrlpq07.coge 0.0% 0 1 1 17.1 17.1 17.1 7.|-- 206.223.224.225 0.0% 0 1 1 16.8 16.8 16.8 8.|-- ??? 100.0 1 0 1 0.0 0.0 0.0 BlackBox:~ jlixfeld$ Thanks! From jra at baylink.com Sat Feb 8 00:10:24 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Feb 2014 19:10:24 -0500 (EST) Subject: SIP on FTTH systems In-Reply-To: Message-ID: <23930591.7506.1391818224549.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mikael Abrahamsson" > To the original poster. People using PPPoE for FTTH makes me sad. When > someone suggests this, please just say "go back to the drawingboard, > redo it right". FWIW, when I dug this ground a couple Thanksgivings ago, I was looking at AE over home-run to an MDF; that was 12,000 or so passings in about 3 sqmi, muni. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From anders at abundo.se Sat Feb 8 02:23:20 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Sat, 08 Feb 2014 03:23:20 +0100 Subject: SIP on FTTH systems In-Reply-To: References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> <201402061608.52822.mark.tinka@seacom.mu> <52F3C94E.9010209@abundo.se> Message-ID: <52F59518.9080605@abundo.se> On 2014-02-06 20:04, Mikael Abrahamsson wrote: > No, you don't. It works perfectly well without direct port-to-port > communication, you just have to align L3 configuration with this L2 behavior > (which can be done in IPv6 but not in IPv4). > > IPv6 can be made to work without on-link /64, with only DHCPv6 IA_NA > (optional) and only DHCPv6-PD. This means all communication goes via the > router which then is perfectly aligned with how the L2 looks like with port > isolation/private vlan. Yes, you are of course correct. I was thinking about selective filtering information between ports, but that is stupid/way too complex and most hardware cannot do that in a good way. I guess you still need proxy-ND or similar as described in RFC4389, and you don't accept clients with IP addresses not assigned over DHCPv6. Fair tradeoffs, SLAAC does not work with abuse etc. /Anders From dhill at mindcry.org Sat Feb 8 02:40:35 2014 From: dhill at mindcry.org (David Hill) Date: Fri, 07 Feb 2014 21:40:35 -0500 Subject: Odd Cogentco routing? Message-ID: <52F59923.10803@mindcry.org> Hello - While doing some traceroutes, I have found a few destinations that I found a little odd. For example: 5.|-- bbr01aldlmi-bue-2.aldl.mi.charter.com 0.0% 60 152.1 47.2 8.3 367.6 66.0 6.|-- bbr01sgnwmi-bue-5.sgnw.mi.charter.com 0.0% 60 102.3 53.4 15.6 317.9 66.3 7.|-- be4041.nr21.b016069-0.dtw04.atlas.cogentco.com 0.0% 60 78.9 58.3 19.6 267.9 62.1 8.|-- te0-5-0-5.rcr21.dtw04.atlas.cogentco.com 0.0% 60 32.6 58.2 20.3 218.3 54.6 9.|-- te4-2.ccr01.tol01.atlas.cogentco.com 0.0% 60 359.6 95.2 21.4 359.6 84.5 10.|-- te0-5-0-1.ccr21.cle04.atlas.cogentco.com 0.0% 60 24.3 70.0 24.3 219.3 52.5 11.|-- te7-2.ccr01.buf02.atlas.cogentco.com 0.0% 60 29.3 89.9 28.8 245.4 66.0 12.|-- te7-2.ccr01.yhm01.atlas.cogentco.com 0.0% 60 117.6 105.0 30.6 467.8 87.7 13.|-- te0-7-0-34.ccr21.yyz02.atlas.cogentco.com 0.0% 60 167.5 65.8 32.0 316.7 51.7 14.|-- level3.yyz02.atlas.cogentco.com 15.0% 60 132.0 91.2 47.6 326.1 57.9 15.|-- ae-13-13.bar1.Toronto1.Level3.net 61.7% 60 62.4 107.9 49.5 282.7 73.0 16.|-- ae-9-9.ebr1.Chicago1.Level3.net 0.0% 60 92.4 116.8 69.6 315.0 59.2 17.|-- ae-1-100.ebr2.Chicago1.Level3.net 1.7% 60 92.3 127.7 71.2 370.1 62.1 18.|-- ae-3-3.ebr2.Atlanta2.Level3.net 0.0% 60 74.6 125.5 70.7 261.0 50.3 19.|-- ae-2-52.edge4.Atlanta2.Level3.net 0.0% 60 75.0 121.0 71.0 252.4 45.6 Detroit -> Toledo -> Cleveland -> Buffalo -> Hamilton, ON -> Toronto -> Chicago.. Is it odd that Cogentco is routing USA traffic to Canada and handing it off there to Level3 just to bring it back in to the USA? There is also some packetloss at the exchange... Thanks, David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From anders at abundo.se Sat Feb 8 02:41:55 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Sat, 08 Feb 2014 03:41:55 +0100 Subject: SIP on FTTH systems In-Reply-To: <201402062149.47240.mark.tinka@seacom.mu> References: <52F31523.4000602@vaxination.ca> <201402061608.52822.mark.tinka@seacom.mu> <52F3C94E.9010209@abundo.se> <201402062149.47240.mark.tinka@seacom.mu> Message-ID: <52F59973.3030801@abundo.se> > Active-E and GPON AN's support split horizons where shared > VLAN's allow for simple service delivery to the CPE, but do > not permit inter-customer communications at Layer 2. Yes. > All communications happens upstream at the BNG, which works > for IPv4 and IPv6. > And no, Proxy ARP is recommended for my competitors. If > you're not my competitor, suggest you turn it off if you > want happiness. So, as I wrote to Mikael, don't you need to use proxy-ARP or proxy-ND to get devices in same L2 domain to be able to communicate? They are on same subnet so they will ARP/ND for each other. > The system specs. are impressive - basically, a little BNG > in a switch, which I can't complain with. There is no rocket science here. Scripting in routers/switches seems to be more common, Cisco has TCL and some Nexus and Arista boxes do Python. There is only some hooks into the control/forwarding plane needed to do advanced services in access. Forwarding plane is covered mostly by SDN so half the work is done. In a 24/48 port access switch there are few clients, so scripting performance is not a problem. > But, if I'm a business with a low start-up budget focused on > broadband services, or lots of cash with no plans to break > into the enterprise or service provider markets, the > PacketFront make sense. My only concern would be NG-MVPN > support - does the PacketFront have that? They working on all the MPLS stuff to be able to sell L2 and L3 VPN services. > Well: > - I support DHCP instead of PPPoE for subscriber > management. > - I support decentralized rather than centralized > BNG's. > - I support Active-E rather than GPON. > > These are all relatively less-than-popular scenarios based > on many of the deployments I've seen in previous years. Agree, the above list is music in my ears :) /Anders From anders at abundo.se Sat Feb 8 03:57:22 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Sat, 08 Feb 2014 04:57:22 +0100 Subject: SIP on FTTH systems In-Reply-To: References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> Message-ID: <52F5AB22.4050500@abundo.se> On 2014-02-07 07:14, Mikael Abrahamsson wrote: > and for IPv6 it's easily solvable by not announcing an on-link network so they > won't even try to communicate directly with each other but instead everything > is routed via the ISP upstream router and then down again to the other > customer CPE/computer. I'm curious on the details: 1) Do you give the client 64 bit using RA (with the A and L bit cleared), 64 bit using DHCPv6, then force the traffic through the default since on-link is not set? Has there been any test if modern operating systems honor this? (I've seen some firewalls doing this, not sure it was by design, they changed the default in later code) 2) Do you only use link-local on the customer port, and use a L3 CPE & DHCP-PD? Always a learning experience reading Nanog.... /Anders From swmike at swm.pp.se Sat Feb 8 04:34:51 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 8 Feb 2014 05:34:51 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <52F59518.9080605@abundo.se> References: <52F31523.4000602@vaxination.ca> <201402061001.21028.mark.tinka@seacom.mu> <52F39377.4020902@abundo.se> <201402061608.52822.mark.tinka@seacom.mu> <52F3C94E.9010209@abundo.se> <52F59518.9080605@abundo.se> Message-ID: On Sat, 8 Feb 2014, Anders L?winger wrote: > I guess you still need proxy-ND or similar as described in RFC4389, and > you don't accept clients with IP addresses not assigned over DHCPv6. > Fair tradeoffs, SLAAC does not work with abuse etc. No, you don't need to do Proxy-ND either. With this solution there is no need for the users to talk directly to each other, even though they're sitting in the same vlan. They have no clue about each other and don't need to know because they will have a prefix delegated to their LL address and a default gateway, and perhaps an IA_NA if the ISP wants to, but that's it. -- Mikael Abrahamsson email: swmike at swm.pp.se From seitz at bsd-unix.net Sat Feb 8 04:35:25 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Fri, 7 Feb 2014 23:35:25 -0500 Subject: Need trusted NTP Sources In-Reply-To: <52F542D6.50104@one.verizon.com> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> <52F4FA6A.60807@gmail.com> <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> <52F542D6.50104@one.verizon.com> Message-ID: <20140208043525.GA2016@bsd-unix.net> On Fri, Feb 07, 2014 at 03:32:22PM -0500, Anthony Williams wrote: > > With a quick and easy mod, another option for $35 is a Sure Electronics > GPS board. > > GPS: http://www.sureelectronics.net/goods.php?id=99 > > Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm > > -Alby > > > On 2/7/2014 1:14 PM, Jared Mauch wrote: > > Having a number of NTP servers will help you detect false tickers which may be critical. > > > > If you want something that is "cheap" as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. The SureGPS is decent fun but i've had this device lose sync / crap out randomly as well. I am using the Garmin 18X-LVC + a low power server with pretty good success. (Requires PPS soldering + USB pigtail for power, pretty easy mod) [seitz at ntp-gps ~]$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== clock.fmt.he.ne .CDMA. 1 u 53 64 377 76.692 0.976 0.291 time-a.timefreq .ACTS. 1 u 39 64 377 48.140 -0.896 0.348 time-b.timefreq .ACTS. 1 u 56 64 377 48.800 -0.986 0.430 time-b.nist.gov .ACTS. 1 u 48 64 377 7.333 3.630 0.562 oGPS_NMEA(1) .PPS. 0 l 4 16 377 0.000 0.002 0.000 * GPS is on a http://us.shuttle.com/barebone/Models/XS36VL.html - chosen for the dual external serial ports. -- Bryan G. Seitz From swmike at swm.pp.se Sat Feb 8 04:38:29 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 8 Feb 2014 05:38:29 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <52F5AB22.4050500@abundo.se> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> Message-ID: On Sat, 8 Feb 2014, Anders L?winger wrote: > > I'm curious on the details: > > 1) > > Do you give the client 64 bit using RA (with the A and L bit cleared), 64 bit > using DHCPv6, then force the traffic through the default since on-link is not > set? Correct. > Has there been any test if modern operating systems honor this? Well, they would be defective if they didn't. Also, you don't even need to announce the prefix at all, even with L-bit cleared. You can make RAs with M and O bit set that won't contain any prefix at all. Been there, done that. At least linux worked perfectly. > Do you only use link-local on the customer port, and use a L3 CPE & > DHCP-PD? That's one way of doing it, or you give it an IA_NA as well if you want a WAN address. -- Mikael Abrahamsson email: swmike at swm.pp.se From mjcrevier at gmail.com Fri Feb 7 16:26:55 2014 From: mjcrevier at gmail.com (Matthew Crevier) Date: Fri, 7 Feb 2014 11:26:55 -0500 Subject: NANOG Digest, Vol 73, Issue 42 In-Reply-To: References: Message-ID: Ntp.nasa.gov never fails me. Matt On Feb 7, 2014 10:56 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Need trusted NTP Sources (Jimmy Hess) > 2. RE: SIP on FTTH systems (Frank Bulk) > 3. Re: carrier comparison (Vlade Ristevski) > 4. Re: carrier comparison (Faisal Imtiaz) > 5. Re: SIP on FTTH systems (Mark Tinka) > 6. Re: carrier comparison (Mark Tinka) > 7. Re: Need trusted NTP Sources (Roy) > 8. Re: SIP on FTTH systems (Jay Ashworth) > 9. Re: SIP on FTTH systems (Mark Tinka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 Feb 2014 06:38:06 -0600 > From: Jimmy Hess > To: Saku Ytti > Cc: NANOG list > Subject: Re: Need trusted NTP Sources > Message-ID: > < > CAAAwwbU+CiTpjXjyAQE1rCT8EE+jX4XhywFPvOC+p4dw6YZPbA at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Feb 7, 2014 at 5:35 AM, Saku Ytti wrote: > > > On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > > > > > My usual practice is to set up two in house servers, each of which > > > talks to: > > Two is worst possible amount of NTP servers to have. Either one fails and > > your timing is wrong, because you cannot vote false ticker. And chance of > > either of > > two failing is higher than one specific of them. > > > > +1 to having at least 3 NTP servers. > Because complete outage is only one kind of failure. > > Don't forget poor performance due to high latency, or > Server X emitting corrupted or inaccurate data > > > -- > -JH > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Feb 2014 07:30:08 -0600 > From: "Frank Bulk" > To: "'Jay Ashworth'" , "NANOG" > Subject: RE: SIP on FTTH systems > Message-ID: <00b401cf2408$b846cde0$28d469a0$@iname.com> > Content-Type: text/plain; charset="UTF-8" > > Rather than assign residential and business customers their own /30, to > conserve space we give those customers a /32 out of a /24. But when one of > these static IP customers wants to send email to another, or the employee > wants to VPN into work, they can't. MACFF is supposed to solve that (we > haven't turned it on, yet, because the vendor's implementation requires us > to do some work on our provisioning system to make it easier). > > Frank > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, February 06, 2014 11:59 PM > To: NANOG > Subject: Re: SIP on FTTH systems > > ----- Original Message ----- > > From: "Frank Bulk" > > > And then you need MACFF to overcome the split-horizon to that > > customers in the same subnet can talk to each other. =) > > In my not-at-all humble opinion, in an eyeball network, you almost *never* > want to make it easier for houses to talk to one another directly; there > isn't any "real" traffic there. Just attack traffic. > > Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > > > > > > > ------------------------------ > > Message: 3 > Date: Fri, 07 Feb 2014 09:19:15 -0500 > From: Vlade Ristevski > To: nanog at nanog.org > Subject: Re: carrier comparison > Message-ID: <52F4EB63.7020806 at ramapo.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I'm not setting it on my router locally but sending it over to Cogent as > a community string per page 22 of their user guide. > > > http://cogentco.com/files/docs/customer_service/guide/global_cogent_customer_user_guide.pdf > > They use it to manipulate how traffic gets back to me so that is > incoming from my routers view. > > I also pad the AS for the networks that I prefer to come back through > the other ISP.. > > > On 2/7/2014 5:27 AM, Olivier Benghozi wrote: > > Hi Vlade, > > > > Well, if you are trying to balance the incoming traffic load with > local-pref attribute, I can understand your disappointment :) > > Since it doesn't work at all this way: local-pref is local to an AS and > deals with outgoing traffic only. > > > >> B) We have our own AS and IP space. I advertise them to both Cogent > and our other ISP. I use the local preference attribute to share the load > for incoming traffic between both ISPs. In the last 5 outages over the last > few years, this has happened twice. I'm waiting on the RFO so I can further > investigate why this happened. I think someone mentioned this in a post a > few months ago too. > > > > -- > Vlade Ristevski > Network Manager > IT Services > Ramapo College > (201)-684-6854 > > > > > ------------------------------ > > Message: 4 > Date: Fri, 7 Feb 2014 14:49:09 +0000 (GMT) > From: Faisal Imtiaz > To: Olivier Benghozi > Cc: nanog at nanog.org > Subject: Re: carrier comparison > Message-ID: > <693349979.661671.1391784549000.JavaMail.root at snappytelecom.net> > Content-Type: text/plain; charset=utf-8 > > Based on my understanding on BFD, it will not help you... BFD will detect > the direct connected port being down quicker and force the BGP session > down, (faster than the time BGP session timers take to determine something > is broken) > > This is the common issue / challenge in how to determine up-stream path > outage and then doing appropriate route engineering on an automatic basis. > > Maybe a SLA monitor type scripting/configuration be useful in your case. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Olivier Benghozi" > > To: nanog at nanog.org > > Sent: Friday, February 7, 2014 5:25:53 AM > > Subject: Re: carrier comparison > > > > Hi Faisal, > > > > > You might have to deploy some other means of (script ?) to bring your > BGP > > > session down from the 'broken' Service Provider. > > > > > > To the best of my knowledge, BGP does not have any mechanism to > determine > > > broken connectivity upstream past the router you are BGP session is up > > > with. > > > > Well, technically there's BFD that might do the trick. But of course it > won't > > be available; it's not usually, so specially with Cogent... :) > > But maybe its link was just overloaded in fact. > > > > > > -- > > Olivier > > > > > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 7 Feb 2014 17:20:08 +0200 > From: Mark Tinka > To: nanog at nanog.org > Subject: Re: SIP on FTTH systems > Message-ID: <201402071720.12145.mark.tinka at seacom.mu> > Content-Type: text/plain; charset="us-ascii" > > On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: > > > Rather than assign residential and business customers > > their own /30, to conserve space we give those customers > > a /32 out of a /24. But when one of these static IP > > customers wants to send email to another, or the > > employee wants to VPN into work, they can't. > > This is akin to Private VLAN's where ports in a shared VLAN > are assigned numbers from the same subnet, but they can only > communicate via the BNG rather than directly at the bridge > level. > > I prefer EVC Split Horizon to Private VLAN's, though. > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20140207/be185b23/attachment-0001.bin > > > > ------------------------------ > > Message: 6 > Date: Fri, 7 Feb 2014 17:21:46 +0200 > From: Mark Tinka > To: nanog at nanog.org > Subject: Re: carrier comparison > Message-ID: <201402071721.47057.mark.tinka at seacom.mu> > Content-Type: text/plain; charset="us-ascii" > > On Friday, February 07, 2014 04:49:09 PM Faisal Imtiaz > wrote: > > > Based on my understanding on BFD, it will not help you... > > BFD will detect the direct connected port being down > > quicker and force the BGP session down, (faster than the > > time BGP session timers take to determine something is > > broken) > > You would also need your provider to support BFD (and by > support I mostly mean willing to run, as modern gear today > is technically capable). > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20140207/b2db7fc3/attachment-0001.bin > > > > ------------------------------ > > Message: 7 > Date: Fri, 07 Feb 2014 07:23:22 -0800 > From: Roy > To: nanog at nanog.org > Subject: Re: Need trusted NTP Sources > Message-ID: <52F4FA6A.60807 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/7/2014 3:35 AM, Saku Ytti wrote: > > On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > > > >> My usual practice is to set up two in house servers, each of which > >> talks to: > >> > >> And then point everyone in house to both of them, assuming they accept > >> multiple server names. > > Two is worst possible amount of NTP servers to have. Either one fails > and your > > timing is wrong, because you cannot vote false ticker. And chance of > either of > > two failing is higher than one specific of them. > > > > "A man with a watch knows what time it is. A man with two watches is > never sure." > > > > ------------------------------ > > Message: 8 > Date: Fri, 07 Feb 2014 10:41:44 -0500 > From: Jay Ashworth > To: mark.tinka at seacom.mu,Mark Tinka > ,nanog at nanog.org > Subject: Re: SIP on FTTH systems > Message-ID: <3db10818-3072-482b-b619-5a884e10d538 at email.android.com> > Content-Type: text/plain; charset=UTF-8 > > I would assume that this whole mostly depends on which particular > protocols and approaches your edge equipment can implement most efficiently > - efficiently enough, that is, to be able to do it on every single port in > a chassis. > > On February 7, 2014 10:20:08 AM EST, Mark Tinka > wrote: > >On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: > > > >> Rather than assign residential and business customers > >> their own /30, to conserve space we give those customers > >> a /32 out of a /24. But when one of these static IP > >> customers wants to send email to another, or the > >> employee wants to VPN into work, they can't. > > > >This is akin to Private VLAN's where ports in a shared VLAN > >are assigned numbers from the same subnet, but they can only > >communicate via the BNG rather than directly at the bridge > >level. > > > >I prefer EVC Split Horizon to Private VLAN's, though. > > > >Mark. > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > ------------------------------ > > Message: 9 > Date: Fri, 7 Feb 2014 17:53:01 +0200 > From: Mark Tinka > To: Jay Ashworth > Cc: nanog at nanog.org > Subject: Re: SIP on FTTH systems > Message-ID: <201402071753.01608.mark.tinka at seacom.mu> > Content-Type: text/plain; charset="us-ascii" > > On Friday, February 07, 2014 05:41:44 PM Jay Ashworth wrote: > > > I would assume that this whole mostly depends on which > > particular protocols and approaches your edge equipment > > can implement most efficiently - efficiently enough, > > that is, to be able to do it on every single port in a > > chassis. > > Well, Split Horizon would be enabled on all the customer- > facing ports. > > I am not aware of any protocol restrictions when running > Split Horizon. I haven't run into any issues yet. > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20140207/5ac5a1fc/attachment.bin > > > > End of NANOG Digest, Vol 73, Issue 42 > ************************************* > From piu at pmgroupuk.com Fri Feb 7 15:20:40 2014 From: piu at pmgroupuk.com (Praveen Unnikrishnan) Date: Fri, 7 Feb 2014 15:20:40 +0000 Subject: GEO location issue with google Message-ID: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> Hi, We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. Could anyone please help me to sort this out? Would be much appreciated for your time. Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: piu at pmgroupuk.com [cid:image001.png at 01CF2418.27F29CA0] [cid:image002.jpg at 01CE1663.96B300D0] www.pmgroupuk.com | www.pmgchosting.com How am I doing? Contact my manager, click here. ________________________________ [cid:image003.jpg at 01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC(r) is a registered trademark of PMGC Technology Group Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 184 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6879 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 14829 bytes Desc: image003.jpg URL: From jof at thejof.com Sat Feb 8 06:35:38 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Fri, 7 Feb 2014 22:35:38 -0800 Subject: GEO location issue with google In-Reply-To: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: Here's the FAQ on this topic: https://support.google.com/websearch/answer/873?hl=en It links to a contact form where you can ask for some redress. Cheers, jof On Fri, Feb 7, 2014 at 7:20 AM, Praveen Unnikrishnan wrote: > Hi, > > We are an ISP based in UK. We have got an ip block from RIPE which is > 5.250.176.0/20. All the main search engines like yahoo shows we are based > in UK. But Google thinks we are from Saudi Arabia and we redirected to > www.google.com.sa instead of googlw.co.uk. I > have sent lot of emails to google but no luck. All the information from > google are in Arabic and youtube shows some weird videos as well. > > Could anyone please help me to sort this out? > > Would be much appreciated for your time. > > Praveen Unnikrishnan > Network Engineer > PMGC Technology Group Ltd > T: 020 3542 6401 > M: 07827921390 > F: 087 1813 1467 > E: piu at pmgroupuk.com > > [cid:image001.png at 01CF2418.27F29CA0] > > > [cid:image002.jpg at 01CE1663.96B300D0] > www.pmgroupuk.com | www.pmgchosting.com < > http://www.pmgchosting.com/> > How am I doing? Contact my manager, click here ?subject=How's%20Praveen%20doing?>. > > ________________________________ > [cid:image003.jpg at 01CE1663.96B300D0] > > PMGC Managed Hosting is now live! After a successful 2012, PMGC continues > to innovate and develop by offering tailored IT solutions designed to > empower you through intelligent use of technologies. www.pmgchosting.com< > http://www.pmgchosting.com/>. > > PMGC Technology Group Limited is a company registered in England and > Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, > London. W1F 7TE). This message contains confidential (and potentially > legally privileged) information solely for its intended recipients. Others > may not distribute copy or use it. If you have received this communication > in error please contact the sender as soon as possible and delete the email > and any attachments without keeping copies. Any views or opinions presented > are solely those of the author and do not necessarily represent those of > the company or its associated companies unless otherwise specifically > stated. All incoming and outgoing e-mails may be monitored in line with > current legislation. It is the responsibility of the recipient to ensure > that emails are virus free before opening. > > PMGC(r) is a registered trademark of PMGC Technology Group Ltd. > > > From mark.tinka at seacom.mu Sat Feb 8 06:42:22 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 8 Feb 2014 08:42:22 +0200 Subject: SIP on FTTH systems In-Reply-To: <52F59973.3030801@abundo.se> References: <52F31523.4000602@vaxination.ca> <201402062149.47240.mark.tinka@seacom.mu> <52F59973.3030801@abundo.se> Message-ID: <201402080842.25258.mark.tinka@seacom.mu> On Saturday, February 08, 2014 04:41:55 AM Anders L?winger wrote: > So, as I wrote to Mikael, don't you need to use proxy-ARP > or proxy-ND to get devices in same L2 domain to be able > to communicate? They are on same subnet so they will > ARP/ND for each other. No, you don't, and you don't want to either. You customers will have visibility to one another at Layer 2 if you don't enable Split Horizon, MAC-FF, Private VLAN's, or whatever implementation your favorite vendor uses to prevent inter-communication between customers in a shared VLAN at the AN/bridge level. While it seems sensible, it normally isn't a good idea. The majority of what will take place between customers at Layer 2 is dirt. Best to run them through a Layer 3 device upstream and apply appropriate filtering. > There is no rocket science here. Scripting in > routers/switches seems to be more common, Cisco has TCL > and some Nexus and Arista boxes do Python. > > There is only some hooks into the control/forwarding > plane needed to do advanced services in access. > Forwarding plane is covered mostly by SDN so half the > work is done. > > In a 24/48 port access switch there are few clients, so > scripting performance is not a problem. I'm more impressed by the braveness of this implementation, than the actual implementation itself, I mean. In our case, given the number of customers in question that would terminate on a BNG (be it a small switch or big router), long term control plane performance is a huge concern, as well as how the hardware handles Multicast and other corner-case services in various topologies. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Feb 8 06:55:52 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 8 Feb 2014 08:55:52 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> Message-ID: <201402080855.55432.mark.tinka@seacom.mu> On Saturday, February 08, 2014 06:38:29 AM Mikael Abrahamsson wrote: > That's one way of doing it, or you give it an IA_NA as > well if you want a WAN address. We prefer DHCP_IA_NA to ND/RA. But yes, either option works. Just depends on operator choice as well as BNG and CPE support. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From swmike at swm.pp.se Sat Feb 8 07:08:43 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 8 Feb 2014 08:08:43 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <201402080855.55432.mark.tinka@seacom.mu> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> <201402080855.55432.mark.tinka@seacom.mu> Message-ID: On Sat, 8 Feb 2014, Mark Tinka wrote: > On Saturday, February 08, 2014 06:38:29 AM Mikael > Abrahamsson wrote: > >> That's one way of doing it, or you give it an IA_NA as >> well if you want a WAN address. > > We prefer DHCP_IA_NA to ND/RA. I have never heard anyone refer to SLAAC as IA_NA. I meant the DHCP kind. When saying IA_NA and IA_PD, you should take for granted people mean DHCP. -- Mikael Abrahamsson email: swmike at swm.pp.se From me at anuragbhatia.com Sat Feb 8 08:08:13 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 8 Feb 2014 13:38:13 +0530 Subject: Blocking of domain strings in iptables Message-ID: Hello everyone I am trying to figure out the way to drop a domain name DNS resolution before it hits application server. I do not want to do domain to IP mapping and block destination IP (and source IP blocking is also not an option). I can see that a string like this: iptables -A INPUT -p udp -m udp --dport 53 -m string --string "domain" --algo kmp --to 65535 -j DROP this can block "domain" which includes domain.com/domain.net and everything in that pattern. I tried using hexadecimal string for value like domaincom (hexa equivalent) and firewall doesn't pics that at all. The only other option which I found to be working nicely is u32 based string as something suggested on DNS amplification blog post here - http://dnsamplificationattacks.blogspot.in/2013/12/domain-dnsamplificationattackscc.html A string like this as suggested on above link works exactly for that domain iptables --insert INPUT -p udp --dport 53 -m u32 --u32 "0x28&0xFFDFDFDF=0x17444e53 && 0x2c&0xDFDFDFDF=0x414d504c && 0x30&0xDFDFDFDF=0x49464943 && 0x34&0xDFDFDFDF=0x4154494f && 0x38&0xDFDFDFDF=0x4e415454 && 0x3c&0xDFDFDFDF=0x41434b53 && 0x40&0xFFDFDFFF=0x02434300" -j DROP -m comment --comment "DROP DNS Q dnsamplificationattacks.cc" but here I am not sure how to create such string out and script them for automation. Can someone suggest a way out for this within IPTables or may be some other open source firewall? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From mark.tinka at seacom.mu Sat Feb 8 08:21:40 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 8 Feb 2014 10:21:40 +0200 Subject: SIP on FTTH systems In-Reply-To: References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <201402080855.55432.mark.tinka@seacom.mu> Message-ID: <201402081021.43182.mark.tinka@seacom.mu> On Saturday, February 08, 2014 09:08:43 AM Mikael Abrahamsson wrote: > I have never heard anyone refer to SLAAC as IA_NA. Because it's not. I said "prefer DHCP_IA_NA to ND/RA". > When saying IA_NA and IA_PD, you should take for granted > people mean DHCP. Anders asked whether ND/RA for the CPE WAN address + DHCP_IA_PD (commonly written as DHCP-PD) is a valid option, to which you replied DHCP_IA_NA can be used for the CPE WAN address as well, to which I added I prefer (over ND/RA, that is). Again, violent agreement, Mikael. Whether I write "DHCP_IA_NA or just IA_NA", "DHCP_IA_PD or just DHCP-PD" it is all implicitly understood to mean "the DHCP kind". Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jof at thejof.com Sat Feb 8 08:34:45 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 8 Feb 2014 00:34:45 -0800 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: This is going to be tricky to do, as DNS packets don't necessarily contain entire query values or FQDNs as complete strings due to packet label compression (remember, original DNS only has 512 bytes to work with). You can use those u32 module matches to find some known-bad packets if they're sufficiently unique, but it simply lacks enough logic to fully parse DNS queries. Here's an interesting example to visualize what's happening: http://dnsamplificationattacks.blogspot.com/p/iptables-block-list.html One quick thing that would work would be to match a single label (e.g. "google", but not "google.com"), but this will end up blocking any frames with that substring in it (e.g. you want to block "evil.com", but this also blocks "evil.example.com"). If you find yourself needing to parse and block DNS packets based on their content in a more flexible way, I would look into either making an iptables module that does the DNS parsing ( http://inai.de/documents/Netfilter_Modules.pdf), or using a userspace library like with NFQUEUE (e.g. https://pypi.python.org/pypi/NetfilterQueue) or l7-filter (http://l7-filter.sourceforge.net/). Best of luck and happy hacking! Cheers, jof On Sat, Feb 8, 2014 at 12:08 AM, Anurag Bhatia wrote: > Hello everyone > > > I am trying to figure out the way to drop a domain name DNS resolution > before it hits application server. I do not want to do domain to IP mapping > and block destination IP (and source IP blocking is also not an option). > > I can see that a string like this: > > iptables -A INPUT -p udp -m udp --dport 53 -m string --string "domain" > --algo kmp --to 65535 -j DROP > > > this can block "domain" which includes domain.com/domain.net and > everything > in that pattern. I tried using hexadecimal string for value like domaincom > (hexa equivalent) and firewall doesn't pics that at all. > > The only other option which I found to be working nicely is u32 based > string as something suggested on DNS amplification blog post here - > > http://dnsamplificationattacks.blogspot.in/2013/12/domain-dnsamplificationattackscc.html > > > A string like this as suggested on above link works exactly for that domain > > iptables --insert INPUT -p udp --dport 53 -m u32 --u32 > "0x28&0xFFDFDFDF=0x17444e53 && 0x2c&0xDFDFDFDF=0x414d504c && > 0x30&0xDFDFDFDF=0x49464943 && 0x34&0xDFDFDFDF=0x4154494f && > 0x38&0xDFDFDFDF=0x4e415454 && 0x3c&0xDFDFDFDF=0x41434b53 && > 0x40&0xFFDFDFFF=0x02434300" -j DROP -m comment --comment "DROP DNS Q > dnsamplificationattacks.cc" > > > but here I am not sure how to create such string out and script them for > automation. > > > > Can someone suggest a way out for this within IPTables or may be some other > open source firewall? > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter > Skype: anuragbhatia.com > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 > From maillist at webjogger.net Sat Feb 8 14:07:05 2014 From: maillist at webjogger.net (Adam Greene) Date: Sat, 8 Feb 2014 09:07:05 -0500 Subject: carrier comparison In-Reply-To: <1071594870.664942.1391809368351.JavaMail.root@snappytelecom.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F5489C.9090409@ramapo.edu> <1071594870.664942.1391809368351.JavaMail.root@snappytelecom.net> Message-ID: <011f01cf24d7$0c1d5050$2457f0f0$@webjogger.net> Hi all, Just wanted to say thanks to all who replied on and off list to my original inquiry. I'd sum up feedback as follows: - Although Cogent has been surprisingly good for some, in general almost everyone agreed that it should never be relied upon as your main Internet provider. As a secondary link, they are a good value. - People had generally good feedback about Level3 - Having one carrier provide service over another carrier?s fiber is generally not a problem. Sometimes it adds complication when things go wrong (and a couple people had some pretty extreme cases to share), but in general most people did not recommend shying away from this kind of relationship. - Time Warner also received positive reviews in general as a carrier I was also surprised how many small ISPs like us are on the NANOG list. I kinda assumed most of you were big operators that dwarf us. It's great to have received perspectives from both large and small operators. Thanks again, everyone. Adam -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: Friday, February 07, 2014 4:43 PM To: Vlade Ristevski Cc: nanog list Subject: Re: carrier comparison This is exactly what I thought had happened....The outage that affected you was one our two routers up-stream from your connection to that provider. I am not trying to defend any Carrier, but there is no 'routing protocol' what will react to this kind of an issue..... Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Vlade Ristevski" > Cc: "nanog list" > Sent: Friday, February 7, 2014 3:57:00 PM > Subject: Re: carrier comparison > > We don't get a default route from them. At the time of the outage my > bgp session was up and I had a full routing table from them. I didn't > have much time to troubleshoot it in that state since we were down so > I had to disable the session ASAP. Once the RFO comes in, I'll be > asking a lot more questions about it. My only experience with BGP is > as a customer so I'm not too familiar with the intricacies on the > provider side. We had an outage in the AM the same day and we failed > over just fine. I'm very curious why the same didn't happen in the evening. > > > > On 2/7/2014 3:03 PM, Bryan Socha wrote: > > Did you verify your problem was announcements on the other side of the > > outage? This sounds to me like you are using a bgp announced default > > route from cogent which is always sent. I think the problem was you > > were sending traffic out a path that was broken. Since you mentioned > > your outbound balancing this would explain some packet loss and not > > 100% loss. > > > > > > Bryan Socha > > Network Engineer > > DigitalOcean > > -- > Vlade Ristevski > Network Manager > IT Services > Ramapo College > (201)-684-6854 > > > From bill at herrin.us Sat Feb 8 14:40:27 2014 From: bill at herrin.us (William Herrin) Date: Sat, 8 Feb 2014 09:40:27 -0500 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: On Sat, Feb 8, 2014 at 3:34 AM, Jonathan Lassoff wrote: > This is going to be tricky to do, as DNS packets don't necessarily contain > entire query values or FQDNs as complete strings due to packet label > compression (remember, original DNS only has 512 bytes to work with). Howdy, The DNS query essentially always contains the full string in a sequence. It doesn't *have* to per the protocol but you'll be hard pressed to find a real-world example where it doesn't. The catch is, the dots aren't encoded. The components of the name being queried are separated by a byte indicating the length of the next piece. So, instead of www.google.com the query packet contains www 0x06 google 0x03 com. You can implement this with --hex-string instead of --string but you'll have to convert the entire thing to hex first Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From fergdawgster at mykolab.com Sat Feb 8 16:30:14 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sat, 08 Feb 2014 08:30:14 -0800 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: <52F65B96.1010902@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Have you looked at perhaps using DNS RPZ (Response Policy Zones)? https://dnsrpz.info/ - - ferg On 2/8/2014 12:08 AM, Anurag Bhatia wrote: > Hello everyone > > > I am trying to figure out the way to drop a domain name DNS > resolution before it hits application server. I do not want to do > domain to IP mapping and block destination IP (and source IP > blocking is also not an option). > > I can see that a string like this: > > iptables -A INPUT -p udp -m udp --dport 53 -m string --string > "domain" --algo kmp --to 65535 -j DROP > > > this can block "domain" which includes domain.com/domain.net and > everything in that pattern. I tried using hexadecimal string for > value like domaincom (hexa equivalent) and firewall doesn't pics > that at all. > > The only other option which I found to be working nicely is u32 > based string as something suggested on DNS amplification blog post > here - > http://dnsamplificationattacks.blogspot.in/2013/12/domain-dnsamplificationattackscc.html > > > > > A string like this as suggested on above link works exactly for > that domain > > iptables --insert INPUT -p udp --dport 53 -m u32 --u32 > "0x28&0xFFDFDFDF=0x17444e53 && 0x2c&0xDFDFDFDF=0x414d504c && > 0x30&0xDFDFDFDF=0x49464943 && 0x34&0xDFDFDFDF=0x4154494f && > 0x38&0xDFDFDFDF=0x4e415454 && 0x3c&0xDFDFDFDF=0x41434b53 && > 0x40&0xFFDFDFFF=0x02434300" -j DROP -m comment --comment "DROP DNS > Q dnsamplificationattacks.cc" > > > but here I am not sure how to create such string out and script > them for automation. > > > > Can someone suggest a way out for this within IPTables or may be > some other open source firewall? > > > Thanks. > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL2W5YACgkQKJasdVTchbJ+qAD+NP7VDzOK2m416hCvi0Mm3rq+ WA7kTOGgXWQGuz20F/cA/3YOsrrlYIL0plRPRUW1Qex2zZfhG4Z/pO63zA0u8DBE =AfV6 -----END PGP SIGNATURE----- From tshaw at oitc.com Sat Feb 8 16:46:22 2014 From: tshaw at oitc.com (TR Shaw) Date: Sat, 8 Feb 2014 11:46:22 -0500 Subject: Blocking of domain strings in iptables In-Reply-To: <52F65B96.1010902@mykolab.com> References: <52F65B96.1010902@mykolab.com> Message-ID: <49DA7CE9-00E5-4F1D-90F6-4DCAE394BF88@oitc.com> You could use RPZ but wouldn't something as simple as putting these two entries in a host files meet the mail? Tom On Feb 8, 2014, at 11:30 AM, Paul Ferguson wrote: > Signed PGP part > Have you looked at perhaps using DNS RPZ (Response Policy Zones)? > > https://dnsrpz.info/ > > - ferg > > > On 2/8/2014 12:08 AM, Anurag Bhatia wrote: > > > Hello everyone > > > > > > I am trying to figure out the way to drop a domain name DNS > > resolution before it hits application server. I do not want to do > > domain to IP mapping and block destination IP (and source IP > > blocking is also not an option). > > > > I can see that a string like this: > > > > iptables -A INPUT -p udp -m udp --dport 53 -m string --string > > "domain" --algo kmp --to 65535 -j DROP > > > > > > this can block "domain" which includes domain.com/domain.net and > > everything in that pattern. I tried using hexadecimal string for > > value like domaincom (hexa equivalent) and firewall doesn't pics > > that at all. > > > > The only other option which I found to be working nicely is u32 > > based string as something suggested on DNS amplification blog post > > here - > > http://dnsamplificationattacks.blogspot.in/2013/12/domain-dnsamplificationattackscc.html > > > > > > > > > > A string like this as suggested on above link works exactly for > > that domain > > > > iptables --insert INPUT -p udp --dport 53 -m u32 --u32 > > "0x28&0xFFDFDFDF=0x17444e53 && 0x2c&0xDFDFDFDF=0x414d504c && > > 0x30&0xDFDFDFDF=0x49464943 && 0x34&0xDFDFDFDF=0x4154494f && > > 0x38&0xDFDFDFDF=0x4e415454 && 0x3c&0xDFDFDFDF=0x41434b53 && > > 0x40&0xFFDFDFFF=0x02434300" -j DROP -m comment --comment "DROP DNS > > Q dnsamplificationattacks.cc" > > > > > > but here I am not sure how to create such string out and script > > them for automation. > > > > > > > > Can someone suggest a way out for this within IPTables or may be > > some other open source firewall? > > > > > > Thanks. > > > > > -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david at blue-labs.org Sat Feb 8 16:59:05 2014 From: david at blue-labs.org (David Ford) Date: Sat, 08 Feb 2014 11:59:05 -0500 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: <52F66259.20305@blue-labs.org> I implemented this easily some time ago due to a situation where product development was unable or unwilling to disable open resolvers. i'll post my ruleset then describe it then describe it since it contains multiple functions. Chain INPUT (policy ACCEPT 68M packets, 4377M bytes) pkts bytes target prot opt in out source destination 22M 1423M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 recent: CHECK name: blacklist side: source reject-with icmp-admin-prohibited 34M 2463M find_dnsany udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 Chain FORWARD (policy ACCEPT 460M packets, 298G bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 recent: CHECK name: blacklist side: source reject-with icmp-admin-prohibited 0 0 irc tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 multiport dports 6660:6669,6670 1826M 1144G local_ips all -- * * 0.0.0.0/0 0.0.0.0/0 35387 2569K find_dnsany udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 Chain OUTPUT (policy ACCEPT 39M packets, 316G bytes) pkts bytes target prot opt in out source destination 0 0 irc tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 multiport dports 6660:6669,6670 22M 1423M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 310M 1637G local_ips all -- * * 0.0.0.0/0 0.0.0.0/0 13M 1056M CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 owner UID match 25 CONNMARK set 0x35 13M 1056M find_dnsany udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 Chain find_dnsany (3 references) pkts bytes target prot opt in out source destination 302K 19M limit_dnsany all -- * * 0.0.0.0/0 0.0.0.0/0 u32 "0x0>>0x16&0x3c at 0x8>>0xf&0x1=0x0&&0x0>>0x18&0x1=0x1" STRING match "|0000ff0001|" ALGO name bm FROM 36 TO 70 /* match ANY? queries */ Chain irc (2 references) pkts bytes target prot opt in out source destination 0 0 ULOG all -- * * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 0 nlgroup 30 queue_threshold 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 8 level 4 prefix "[IRC] " 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-admin-prohibited Chain limit_dnsany (1 references) pkts bytes target prot opt in out source destination 827 53727 ACCEPT all -- * * 1.2.3.4 0.0.0.0/0 limit: avg 20/min burst 60 0 0 limit_venet all -- * * 1.2.3.4 0.0.0.0/0 4297 302K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK match 0x35 limit: avg 10/min burst 30 22798 1475K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 4/min burst 10 7277 468K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/min burst 5 LOG flags 0 level 4 prefix "DNSANY: " 279K 18M DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain limit_venet (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/min burst 5 LOG flags 0 level 4 prefix "DNSANYint: " 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-admin-prohibited Chain local_ips (2 references) pkts bytes target prot opt in out source destination 2136M 2782G RETURN all -- * !eth0 0.0.0.0/0 0.0.0.0/0 /* only check outgoing packets */ 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match src-type LOCAL /* accept packet generated from any locally bound IP */ 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 recent: CHECK name: local_ips side: source 0 0 ULOG all -- * * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 0 nlgroup 30 queue_threshold 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/min burst 5 /* block non-local IPs from exiting */ LOG flags 8 level 4 prefix "SPOOF: " 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-admin-prohibited First, INPUT, FORWARD, and OUTPUT are very similar. 1) INPUT accepts all /lo/ traffic as does OUTPUT 2) INPUT and FORWARD auto block any IPs admins put into the //proc/net/ipt_recent/blacklist/ (or //proc/net/xt_recent/blacklist/ depending on kernel version) 3) common IRC port traffic is blocked (insane number of bots use these ports) 4) outgoing IPs are matched to interface IPs. this set of rules are used for when the kernel is too old to employ //proc/sys/net/ipv4/conf/all/rp_filter/ mode against forwarded IPs too (prevents spoofing) 5) OUTPUT tags DNS traffic owned by uid 25 (usually for sendmail, postfix, etc, change accordingly) 6) in order to prevent killing our box with syslog when an attack happens, logging is strictly rate limited now on to the DNS specific stuff 1) each of INPUT, FORWARD, and OUTPUT call /find_dnsany/ to identify our suspect traffic 2) the rule in /find_dnsany/ uses a u32 match rule to first identify DNS traffic that is a query, and a string match to identify the ANY flag, further, we try to make this efficient by limiting our match to the byte range of 36 to 70. we've found that 100% of our DNS amplification attacks request zone data that fits within this. it certainly may be a longer zone but is unlikely. change accordingly 3) once DNS ANY queries have been identified, jump to /limit_dnsany/ 4) /limit_dnsany/ is designed to accept packets until a limit is reached. there are three limits employed: 4.1) customers in a VZ or bound to a specific local IP that may have higher than normal rates of legitimate DNS ANY queries 4.2) our local smtp initiated lookups. qmail is horrible in that it employs DNS ANY (broken design, discussion out of scope) 4.3) all other DNS ANY traffic 5) incoming DNS ANY that is rate limited is DROPped on the floor, rate limited outgoing is REJECted so internal customers get a friendly icmp reject message additional notes: 1) outgoing should also be checked against the blacklist, somehow our QA dropped that rule before disting 2) IRC is checked before local traffic to ensure two infected customers aren't communicating with each other this set of rules reliably filters: 1) incoming and outgoing DNS QUERY floods. incoming is rate limited to 4/min per IP source. forwarded and outgoing has higher limits 2) majority of bot traffic on IRC ports 3) spoofed and blacklisted packets -david On 02/08/2014 03:34 AM, Jonathan Lassoff wrote: > This is going to be tricky to do, as DNS packets don't necessarily contain > entire query values or FQDNs as complete strings due to packet label > compression (remember, original DNS only has 512 bytes to work with). > > You can use those u32 module matches to find some known-bad packets if > they're sufficiently unique, but it simply lacks enough logic to fully > parse DNS queries. > Here's an interesting example to visualize what's happening: > http://dnsamplificationattacks.blogspot.com/p/iptables-block-list.html > > One quick thing that would work would be to match a single label (e.g. > "google", but not "google.com"), but this will end up blocking any frames > with that substring in it (e.g. you want to block "evil.com", but this also > blocks "evil.example.com"). > > If you find yourself needing to parse and block DNS packets based on their > content in a more flexible way, I would look into either making an iptables > module that does the DNS parsing ( > http://inai.de/documents/Netfilter_Modules.pdf), or using a userspace > library like with NFQUEUE (e.g. https://pypi.python.org/pypi/NetfilterQueue) > or l7-filter (http://l7-filter.sourceforge.net/). > > Best of luck and happy hacking! > > Cheers, > jof > > > > On Sat, Feb 8, 2014 at 12:08 AM, Anurag Bhatia wrote: > >> Hello everyone >> >> >> I am trying to figure out the way to drop a domain name DNS resolution >> before it hits application server. I do not want to do domain to IP mapping >> and block destination IP (and source IP blocking is also not an option). >> >> I can see that a string like this: >> >> iptables -A INPUT -p udp -m udp --dport 53 -m string --string "domain" >> --algo kmp --to 65535 -j DROP >> >> >> this can block "domain" which includes domain.com/domain.net and >> everything >> in that pattern. I tried using hexadecimal string for value like domaincom >> (hexa equivalent) and firewall doesn't pics that at all. >> >> The only other option which I found to be working nicely is u32 based >> string as something suggested on DNS amplification blog post here - >> >> http://dnsamplificationattacks.blogspot.in/2013/12/domain-dnsamplificationattackscc.html >> >> >> A string like this as suggested on above link works exactly for that domain >> >> iptables --insert INPUT -p udp --dport 53 -m u32 --u32 >> "0x28&0xFFDFDFDF=0x17444e53 && 0x2c&0xDFDFDFDF=0x414d504c && >> 0x30&0xDFDFDFDF=0x49464943 && 0x34&0xDFDFDFDF=0x4154494f && >> 0x38&0xDFDFDFDF=0x4e415454 && 0x3c&0xDFDFDFDF=0x41434b53 && >> 0x40&0xFFDFDFFF=0x02434300" -j DROP -m comment --comment "DROP DNS Q >> dnsamplificationattacks.cc" >> >> >> but here I am not sure how to create such string out and script them for >> automation. >> >> >> >> Can someone suggest a way out for this within IPTables or may be some other >> open source firewall? >> >> >> Thanks. >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | >> Twitter >> Skype: anuragbhatia.com >> >> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >> From bortzmeyer at nic.fr Sat Feb 8 17:16:45 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 8 Feb 2014 18:16:45 +0100 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: <20140208171644.GB16533@sources.org> On Sat, Feb 08, 2014 at 12:34:45AM -0800, Jonathan Lassoff wrote a message of 88 lines which said: > This is going to be tricky to do, as DNS packets don't necessarily > contain entire query values or FQDNs as complete strings due to > packet label compression Apprently, the OP wanted to match the *question* in a *query* and these are never compressed (they could, in theory, but are not). > You can use those u32 module matches to find some known-bad packets > if they're sufficiently unique, but it simply lacks enough logic to > fully parse DNS queries. u32's language is not Turing-complete but It is sufficient in the case presented here. From bortzmeyer at nic.fr Sat Feb 8 17:14:42 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 8 Feb 2014 18:14:42 +0100 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: <20140208171442.GA16533@sources.org> On Sat, Feb 08, 2014 at 01:38:13PM +0530, Anurag Bhatia wrote a message of 54 lines which said: > but here I am not sure how to create such string out and script them > for automation. Use this program: http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py From dmiller at tiggee.com Sat Feb 8 17:47:09 2014 From: dmiller at tiggee.com (David Miller) Date: Sat, 08 Feb 2014 12:47:09 -0500 Subject: Blocking of domain strings in iptables In-Reply-To: References: Message-ID: <52F66D9D.1000205@tiggee.com> On 02/08/2014 09:40 AM, William Herrin wrote: > On Sat, Feb 8, 2014 at 3:34 AM, Jonathan Lassoff wrote: >> This is going to be tricky to do, as DNS packets don't necessarily contain >> entire query values or FQDNs as complete strings due to packet label >> compression (remember, original DNS only has 512 bytes to work with). > > Howdy, > > The DNS query essentially always contains the full string in a > sequence. It doesn't *have* to per the protocol but you'll be hard > pressed to find a real-world example where it doesn't. > > The catch is, the dots aren't encoded. The components of the name > being queried are separated by a byte indicating the length of the > next piece. So, instead of www.google.com the query packet contains > www 0x06 google 0x03 com. For the completeness of the archives, the length of the first token is also encoded and final terminator is 0. 0x03 www 0x06 google 0x03 com 0x00 -DMM > > You can implement this with --hex-string instead of --string but > you'll have to convert the entire thing to hex first > > Regards, > Bill Herrin > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From msa at latt.net Sat Feb 8 20:53:49 2014 From: msa at latt.net (Majdi S. Abbas) Date: Sat, 8 Feb 2014 15:53:49 -0500 Subject: Need trusted NTP Sources In-Reply-To: <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> References: <13052302.7446.1391739261269.JavaMail.root@benjamin.baylink.com> <20140207113525.GA13919@pob.ytti.fi> <52F4FA6A.60807@gmail.com> <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> <4BF35C9F-4207-4A12-8FA4-1C3721057CEA@puck.nether.net> Message-ID: <20140208205349.GA3278@puck.nether.net> On Fri, Feb 07, 2014 at 01:14:09PM -0500, Jared Mauch wrote: > If you want something that is "cheap" as in you for your home, I can > recommend this: ~$350 w/ antenna, etc.. > > http://www.netburnerstore.com/product_p/pk70ex-ntp.htm > > You can get the whole thing going quickly. Majdi has also had good luck > with this unit (perhaps he wants to chime-in, heh pun unintended) regarding > a few other devices. The Netburner NTP sample app works well enough for basic home use, although I get better timing performance out of a fleet of hand modified Soekrii. I've been modifying NET4801s to include internal Motorola Oncore timing receivers (this is a tight fit, but doable, in the factory cases), or to break out their second serial port for connections to external reference clocks. (I have one connected to a TrueTime TL-3 to use WWV as a backup to GPS, but it can also be a travelling GPS NTP server with, say, a Garmin GPS18lvc connected.) You can make your own sub-$150 NTP server -- I'll spare the list the details, but those that are interested should see: http://puck.nether.net/~majdi/ntp/ Feedback is appreciated -- I've only spent about an hour on this doc, and it assumes a lot of familiarity with FreeBSD. I will try to flesh it out more as I have time. Cheers, --msa From sylvain at gixe.net Sat Feb 8 17:58:39 2014 From: sylvain at gixe.net (Sylvain Vallerot) Date: Sat, 08 Feb 2014 18:58:39 +0100 Subject: GEO location issue with google In-Reply-To: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: <52F6704F.5010101@gixe.net> Hi, On 07/02/2014 16:20, Praveen Unnikrishnan wrote: > We are an ISP based in UK. We have got an ip block from RIPE > which is 5.250.176.0/20. There is a geoloc attribute for the inetnum fields, maybe you could try an set it, just in case someone uses it sometines... Regards, S. Vallerot From jra at baylink.com Sun Feb 9 00:43:36 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Feb 2014 19:43:36 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: <20140207113525.GA13919@pob.ytti.fi> Message-ID: <27402294.7560.1391906616448.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Saku Ytti" > On (2014-02-06 21:14 -0500), Jay Ashworth wrote: > > My usual practice is to set up two in house servers, each of which > > talks to: > > > > And then point everyone in house to both of them, assuming they > > accept multiple server names. > > Two is worst possible amount of NTP servers to have. Either one fails and your > timing is wrong, because you cannot vote false ticker. And chance of either of > two failing is higher than one specific of them. Fair point. In practice, it never bit me because nearly everything that wanted NTP would only accept one server name (being windows) and the things that *did* take more than one, I generally pointed to both internals, and something outside the firewall as well. In the architecture I described, though, is it really true that the odds of the common types of failure are higher than with only one? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Sun Feb 9 00:46:40 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Feb 2014 19:46:40 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: Message-ID: <15331347.7562.1391906800520.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > Don't forget poor performance due to high latency, or > Server X emitting corrupted or inaccurate data My two internal servers were my two uplink firewalls, and were pretty thoroughly monitored. Had NTP gone insane, I've had heard about it. Remember that 3 of the 8 peers on each machine were pool.ntp.org machines, so the cluster, as a cluster, actually had *nine* external peers, each machine having 3 in common, and three which were not (each machine was a DNS resolver, so they didn't share a name cache on "*.us.pool.ntp.org" Cheers, -- jra Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Sun Feb 9 00:48:49 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Feb 2014 19:48:49 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: <483E6B0272B0284BA86D7596C40D29F90233E61638F0@PUR-EXCH07.ox.com> Message-ID: <27574184.7564.1391906929349.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Matthew Huff" > Working in the financial world, the best practices is to have 4 ntp > servers (if not using PTP). > > 1) You need 3 to determine the correct time (and detect bad tickers) > 2) If you lose 1 of the 3 above, then you no longer can determine the > correct time > 3) Therefore with 4, you have redundancy. > > We have two Symmetricom Stratum 1 time servers synced via GPS with > Rubidium oscillators, and two RHEL 6 servers running ntpd for our 4 > servers. As I've noted, I had *nine* external peers; 3 shared by both machines (commercial and NIST strat-1's), and 3 each from us.pool, which were generally different servers; I did keep an eye on that. And the NTP servers were monitored. I'm stupid, but I'm not crazy. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Sun Feb 9 00:52:02 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Feb 2014 19:52:02 -0500 (EST) Subject: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.) In-Reply-To: <7FFBD228-9827-4B84-8EBD-889B0EE82700@arbor.net> Message-ID: <21553345.7566.1391907122569.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Roland Dobbins" > On Feb 8, 2014, at 4:25 AM, Chris Grundemann > wrote: > > > Documenting those various mechanisms which are actually utilized is > > the key here. =) > > Yes, as well as the various limitations and caveats, like the > wholesale/retail issue (i.e., customers of my customer). And anyone who has factual data on that topic is invited to contribute it to (stop me if you've heard this one)... http://www.bcp38.info Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From saku at ytti.fi Sun Feb 9 08:03:46 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 9 Feb 2014 10:03:46 +0200 Subject: Need trusted NTP Sources In-Reply-To: <27402294.7560.1391906616448.JavaMail.root@benjamin.baylink.com> References: <20140207113525.GA13919@pob.ytti.fi> <27402294.7560.1391906616448.JavaMail.root@benjamin.baylink.com> Message-ID: <20140209080346.GA6967@pob.ytti.fi> On (2014-02-08 19:43 -0500), Jay Ashworth wrote: > In the architecture I described, though, is it really true that the odds > of the common types of failure are higher than with only one? I think so, lets assume arbitrarily that probability of NTP server not starting to give incorrect time is 99% over 1 year time. Then either of two servers not giving incorrect time is 0.99**2 i.e. 98%, so two NTP servers would be 1% point more likely to give incorrect time than one over 1 year time. Obviously the chance of working is more than 99% maybe it's something like 99.999%? And is that really typical failure-mode or is typical failure-mode complete loss of connectivity? Two NTP servers would protect from this, single not. However loss-of-connectivity minor impact on clients, wrong time has major impact of client. Maybe if loss-of-connectivity is fixed in somewhat short period of time, single NTP always win, if loss-of-connectivity is fixed typically in very long period of time, single NTP loses. I don't really have exact data, but best practice is >2. Matthew said 4, which gives the advantage that in single failure you are still operating redundantly and do not have urgency to fix, with 3 in single failure another failure must not occur before it is fixed. I think 3 is enough, networks are typically designed to handle 1 arbitrary failure at the same time and 2 arbitrary failures in most networks, when chosen correctly, will cause SLA breaking faults (Cheaper to pay SLA compensations than to recover from any 2 failures). But NTP servers are cheap, so if you want to be robust and recover from n false tickers, have 3+n. -- ++ytti From andriy.bilous at gmail.com Sun Feb 9 20:08:00 2014 From: andriy.bilous at gmail.com (Andriy Bilous) Date: Sun, 9 Feb 2014 21:08:00 +0100 Subject: Need trusted NTP Sources In-Reply-To: <20140209080346.GA6967@pob.ytti.fi> References: <20140207113525.GA13919@pob.ytti.fi> <27402294.7560.1391906616448.JavaMail.root@benjamin.baylink.com> <20140209080346.GA6967@pob.ytti.fi> Message-ID: Best practice is five. =) I don't remember if it's in FAQ on ntp.org or in David Mills' book. Your local clock is kind of gullible "push-over" which will "vote" for the "party" providing most reasonable data. The algorithm would filter out insane sources which run too far from the rest and then group sane sources into 2 "parties" - your clock will follow the one where runners are closer to each other. That is why uneven number of trustworthy sources at least at start is required. With 2 sources you will blindly follow the one which is closer to your own clock. You're also having the the risk to degrade into this situation when you lose 1 out of 3 sources. Four is again 2:2 and only with five you have a good chance to start disciplining your clock into the right direction at the right pace, so when 1 source is lost you (most probably) won't run into insanity. On Sun, Feb 9, 2014 at 9:03 AM, Saku Ytti wrote: > On (2014-02-08 19:43 -0500), Jay Ashworth wrote: > > > In the architecture I described, though, is it really true that the odds > > of the common types of failure are higher than with only one? > > I think so, lets assume arbitrarily that probability of NTP server not > starting to give incorrect time is 99% over 1 year time. > Then either of two servers not giving incorrect time is 0.99**2 i.e. 98%, > so > two NTP servers would be 1% point more likely to give incorrect time than > one > over 1 year time. > > Obviously the chance of working is more than 99% maybe it's something like > 99.999%? And is that really typical failure-mode or is typical failure-mode > complete loss of connectivity? Two NTP servers would protect from this, > single > not. > However loss-of-connectivity minor impact on clients, wrong time has major > impact of client. > Maybe if loss-of-connectivity is fixed in somewhat short period of time, > single NTP always win, if loss-of-connectivity is fixed typically in very > long > period of time, single NTP loses. > > I don't really have exact data, but best practice is >2. Matthew said 4, > which > gives the advantage that in single failure you are still operating > redundantly > and do not have urgency to fix, with 3 in single failure another failure > must > not occur before it is fixed. > I think 3 is enough, networks are typically designed to handle 1 arbitrary > failure at the same time and 2 arbitrary failures in most networks, when > chosen correctly, will cause SLA breaking faults (Cheaper to pay SLA > compensations than to recover from any 2 failures). > But NTP servers are cheap, so if you want to be robust and recover from n > false tickers, have 3+n. > > > > -- > ++ytti > > From jra at baylink.com Sun Feb 9 20:16:25 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 9 Feb 2014 15:16:25 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: <20140209080346.GA6967@pob.ytti.fi> Message-ID: <11574510.7778.1391976985145.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Saku Ytti" > > In the architecture I described, though, is it really true that the > > odds of the common types of failure are higher than with only one? > > I think so, lets assume arbitrarily that probability of NTP server not > starting to give incorrect time is 99% over 1 year time. > Then either of two servers not giving incorrect time is 0.99**2 i.e. 98%, so > two NTP servers would be 1% point more likely to give incorrect time than one > over 1 year time. That's only true if the two devices have common failure modes, though, is it not? -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From saku at ytti.fi Sun Feb 9 20:30:33 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 9 Feb 2014 22:30:33 +0200 Subject: Need trusted NTP Sources In-Reply-To: <11574510.7778.1391976985145.JavaMail.root@benjamin.baylink.com> References: <20140209080346.GA6967@pob.ytti.fi> <11574510.7778.1391976985145.JavaMail.root@benjamin.baylink.com> Message-ID: <20140209203033.GA14868@pob.ytti.fi> On (2014-02-09 15:16 -0500), Jay Ashworth wrote: > > Then either of two servers not giving incorrect time is 0.99**2 i.e. 98%, so > > two NTP servers would be 1% point more likely to give incorrect time than one > > over 1 year time. > > That's only true if the two devices have common failure modes, though, > is it not? No, we can assume arbitrary fault which causes NTP to output bad time. With two NTP servers it's more likely that any one of them will start doing that than with one alone. And if any of the two start doing it, you don't know which one. -- ++ytti From jra at baylink.com Sun Feb 9 20:45:19 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 9 Feb 2014 15:45:19 -0500 (EST) Subject: Need trusted NTP Sources In-Reply-To: <20140209203033.GA14868@pob.ytti.fi> Message-ID: <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Saku Ytti" > > That's only true if the two devices have common failure modes, > > though, is it not? > > No, we can assume arbitrary fault which causes NTP to output bad time. With > two NTP servers it's more likely that any one of them will start doing > that than with one alone. And if any of the two start doing it, you don't > know which one. Hey, waitaminnit! I saw you palm that card. :-) If I'm locked to 2 coherent upstreams and one goes insane, I'm going to know which one it is, because the other one will still match what I already have running, no? Or do I understand NTP less well than I think? Cheres, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From LarrySheldon at cox.net Sun Feb 9 20:50:42 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 09 Feb 2014 14:50:42 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: Message-ID: <52F7EA22.5080805@cox.net> On 2/9/2014 2:45 PM, Jay Ashworth wrote: > Or do I understand NTP less well than I think? I am of the private opinion that if your name is not "David Mill" (and MAYBE if it IS) the answer is either "42" or "yes". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From saku at ytti.fi Sun Feb 9 20:56:11 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 9 Feb 2014 22:56:11 +0200 Subject: Need trusted NTP Sources In-Reply-To: <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> References: <20140209203033.GA14868@pob.ytti.fi> <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> Message-ID: <20140209205611.GA18047@pob.ytti.fi> On (2014-02-09 15:45 -0500), Jay Ashworth wrote: > If I'm locked to 2 coherent upstreams and one goes insane, I'm going to > know which one it is, because the other one will still match what I already > have running, no? > > Or do I understand NTP less well than I think? I don't think you can reasonably tell which of the two is the false ticker. Andriy says your PC would blindly follow one who is in more agreement with your local lock, and PC's have terrible oscillators (I don't know why, 5EUR would buy LOT better oscillator). -- ++ytti From mysidia at gmail.com Sun Feb 9 21:00:29 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 9 Feb 2014 15:00:29 -0600 Subject: Need trusted NTP Sources In-Reply-To: <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> References: <20140209203033.GA14868@pob.ytti.fi> <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Feb 9, 2014 at 2:45 PM, Jay Ashworth wrote: [snip] > If I'm locked to 2 coherent upstreams and one goes insane, I'm going to > know which one it is, because the other one will still match what I already > have running, no? The question should be how assured is the reliability of the clocks of the 2 upstream servers. I think I am pretty happy with the concept of having two local centralized NTP servers, used by various servers in an environment ---- some SNTP some NTP, each of the local centralized NTP servers using 5 external time sources. These external time sources need to be periodically checked, to ensure the central NTP servers continue to synchronize with them, and that they continue to be accurate. So the pair of NTP servers is not redundant in the sense that the time is allowed to be wrong, but they are resilient in the sense of being configured, so their own clock should always be correct, unless there is a once in 100 years failure scenario. Each of the local servers, then has two NTP peers as time source, and the local clock discipline, except for virtual machines: which should use just the two NTP servers. A local pair of NTP servers are not "redundant" in the sense of being able to survive a catastrophic software bug in NTP; the local time sources should be redundant to survive the more highly frequent condition of temporary total failure of a local NTP server. > Or do I understand NTP less well than I think? > Cheres, > -- jra > -- -JH From saku at ytti.fi Sun Feb 9 21:03:28 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 9 Feb 2014 23:03:28 +0200 Subject: Need trusted NTP Sources In-Reply-To: References: <20140207113525.GA13919@pob.ytti.fi> <27402294.7560.1391906616448.JavaMail.root@benjamin.baylink.com> <20140209080346.GA6967@pob.ytti.fi> Message-ID: <20140209210328.GB18047@pob.ytti.fi> On (2014-02-09 21:08 +0100), Andriy Bilous wrote: > Best practice is five. =) I don't remember if it's in FAQ on ntp.org or in > David Mills' book. Your local clock is kind of gullible "push-over" which > will "vote" for the "party" providing most reasonable data. The algorithm > would filter out insane sources which run too far from the rest and then > group sane sources into 2 "parties" - your clock will follow the one where > runners are closer to each other. That is why uneven number of trustworthy > sources at least at start is required. With 2 sources you will blindly > follow the one which is closer to your own clock. You're also having the > the risk to degrade into this situation when you lose 1 out of 3 sources. > Four is again 2:2 and only with five you have a good chance to start > disciplining your clock into the right direction at the right pace, so when > 1 source is lost you (most probably) won't run into insanity. I'm having bit difficulties understanding the issue with 4. Is the implication that you have two groups which all agree with each other reasonably well, but do not agree between the groups. Which would mean that 4 cannot handle situation where 2 develop problem where they agree with each other but are wrong. But even in that case, you'd still recover from 1 of them being wrong. So 3 = correct time, no redundancy 4 = correct time, 1 can fail 5 = correct time, 2 can fail and so forth? But not sure here, just stabbing in the dark. For the fun of it, threw email to Mills, if he replies, I'll patch it back here. -- ++ytti From lyle at lcrcomputer.net Sun Feb 9 21:19:09 2014 From: lyle at lcrcomputer.net (Lyle Giese) Date: Sun, 09 Feb 2014 15:19:09 -0600 Subject: Need trusted NTP Sources In-Reply-To: <20140209205611.GA18047@pob.ytti.fi> References: <20140209203033.GA14868@pob.ytti.fi> <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> <20140209205611.GA18047@pob.ytti.fi> Message-ID: <52F7F0CD.4060207@lcrcomputer.net> Look back in the archives and see the problems that erupted when one of the big guys rebooted and came on line with bad time(tock.usno.navy.mil in Nov of 2012). It was talked about in Outages and other lists at the time it happened. On 02/09/14 14:56, Saku Ytti wrote: > On (2014-02-09 15:45 -0500), Jay Ashworth wrote: > >> If I'm locked to 2 coherent upstreams and one goes insane, I'm going to >> know which one it is, because the other one will still match what I already >> have running, no? >> >> Or do I understand NTP less well than I think? > I don't think you can reasonably tell which of the two is the false ticker. > Andriy says your PC would blindly follow one who is in more agreement with > your local lock, and PC's have terrible oscillators (I don't know why, 5EUR > would buy LOT better oscillator). > From rbf+nanog at panix.com Sun Feb 9 21:36:25 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 9 Feb 2014 15:36:25 -0600 Subject: Need trusted NTP Sources In-Reply-To: <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> References: <20140209203033.GA14868@pob.ytti.fi> <9328684.7780.1391978719937.JavaMail.root@benjamin.baylink.com> Message-ID: <20140209213625.GA25023@panix.com> On Sun, Feb 09, 2014 at 03:45:19PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Saku Ytti" > > > > That's only true if the two devices have common failure modes, > > > though, is it not? > > > > No, we can assume arbitrary fault which causes NTP to output bad time. With > > two NTP servers it's more likely that any one of them will start doing > > that than with one alone. And if any of the two start doing it, you don't > > know which one. > > Hey, waitaminnit! I saw you palm that card. :-) > > If I'm locked to 2 coherent upstreams and one goes insane, I'm going to > know which one it is, because the other one will still match what I already > have running, no? If it suddenly goes insane as a step function? Sure. But if the one you've selected for synchronization starts drifting off true time very slowly, it will take your clock with it, and then ultimately the other one (that is actually the good clock) will appear to be insane clock. -- Brett From andriy.bilous at gmail.com Sun Feb 9 21:41:48 2014 From: andriy.bilous at gmail.com (Andriy Bilous) Date: Sun, 9 Feb 2014 22:41:48 +0100 Subject: Need trusted NTP Sources In-Reply-To: <20140209210328.GB18047@pob.ytti.fi> References: <20140207113525.GA13919@pob.ytti.fi> <27402294.7560.1391906616448.JavaMail.root@benjamin.baylink.com> <20140209080346.GA6967@pob.ytti.fi> <20140209210328.GB18047@pob.ytti.fi> Message-ID: Unfortunately I don't have the book handy. May be I am wrong too. Just checked and 4 looks to be a valid solution for 1 falseticker according to Byzantine Generals' Problem. On Sun, Feb 9, 2014 at 10:03 PM, Saku Ytti wrote: > On (2014-02-09 21:08 +0100), Andriy Bilous wrote: > > > Best practice is five. =) I don't remember if it's in FAQ on ntp.org or > in > > David Mills' book. Your local clock is kind of gullible "push-over" which > > will "vote" for the "party" providing most reasonable data. The algorithm > > would filter out insane sources which run too far from the rest and then > > group sane sources into 2 "parties" - your clock will follow the one > where > > runners are closer to each other. That is why uneven number of > trustworthy > > sources at least at start is required. With 2 sources you will blindly > > follow the one which is closer to your own clock. You're also having the > > the risk to degrade into this situation when you lose 1 out of 3 sources. > > Four is again 2:2 and only with five you have a good chance to start > > disciplining your clock into the right direction at the right pace, so > when > > 1 source is lost you (most probably) won't run into insanity. > > I'm having bit difficulties understanding the issue with 4. > > Is the implication that you have two groups which all agree with each other > reasonably well, but do not agree between the groups. Which would mean > that 4 > cannot handle situation where 2 develop problem where they agree with each > other but are wrong. > But even in that case, you'd still recover from 1 of them being wrong. So > > 3 = correct time, no redundancy > 4 = correct time, 1 can fail > 5 = correct time, 2 can fail > and so forth? > > But not sure here, just stabbing in the dark. For the fun of it, threw > email > to Mills, if he replies, I'll patch it back here. > > -- > ++ytti > > From james.cutler at consultant.com Mon Feb 10 00:42:31 2014 From: james.cutler at consultant.com (James R Cutler) Date: Sun, 9 Feb 2014 19:42:31 -0500 Subject: Need trusted NTP Sources In-Reply-To: <52F7EA22.5080805@cox.net> References: <52F7EA22.5080805@cox.net> Message-ID: On Feb 9, 2014, at 3:50 PM, Larry Sheldon wrote: > On 2/9/2014 2:45 PM, Jay Ashworth wrote: > >> Or do I understand NTP less well than I think? > > I am of the private opinion that if your name is not "David Mill" (and MAYBE if it IS) the answer is either "42" or "yes". > ? ... From http://www.eecis.udel.edu/~mills/database/brief/overview/overview.pdf > Intersection and clustering algorithms pick best true chimers and discard false tickers. You should look at this presentation and see why Larry Sheldon?s private opinion is spot on. I won?t begin to try explaining in technical detail how this works. The bottom line is that, within a peer group of NTP servers looking at a reasonably large set of NTP source servers, all kinds of variations in input data are reduced to a coherent local time truth. My template for NTP service deployment for any organization is very simple: 1. Select four or more local systems and configure them as peer NTP servers. In many instances one can leverage local DNS server machines running almost any OS ? the NTP daemon runs on at least Windows, OS X, UNIX, Linux. Don?t forget appropriate restrict commands. 2. Configure ntpd on the local servers to also select as servers a list of 8-10 open access servers like pool.ntp.org, usno.navy.mil, nist-????-ustiming.org. If you can arrange authenticated access to other servers, that is possibly better. 3. As desired, configure ntpd on selected local servers for local clocks or GPS clocks. This has little effect on accuracy, but may enhance reliability. In many cases, it also requires building penetrations for antennas. (Not easy for network guys.) 4. Configure all local time consumers to select from the list of local NTP servers. Authenticate or not as you see fit. You can even use DHCP to inform end systems of NTP server addresses. The router folks will have to include NTP server addresses as part of each configuration package. Over the years I have successfully applied this template for NTP service deployments to several large networks. It just works. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From LarrySheldon at cox.net Mon Feb 10 01:04:39 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 09 Feb 2014 19:04:39 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: <52F7EA22.5080805@cox.net> Message-ID: <52F825A7.1090208@cox.net> On 2/9/2014 6:42 PM, James R Cutler wrote: > On Feb 9, 2014, at 3:50 PM, Larry Sheldon > wrote: > >> On 2/9/2014 2:45 PM, Jay Ashworth wrote: >> >>> Or do I understand NTP less well than I think? >> >> I am of the private opinion that if your name is not "David Mill" >> (and MAYBE if it IS) the answer is either "42" or "yes". ? ... > > From > http://www.eecis.udel.edu/~mills/database/brief/overview/overview.pdf >> > Intersection and clustering algorithms pick best true chimers and discard false tickers. > You should look at this presentation and see why Larry Sheldon?s > private opinion is spot on. > > I won?t begin to try explaining in technical detail how this works. > The bottom line is that, within a peer group of NTP servers looking > at a reasonably large set of NTP source servers, all kinds of > variations in input data are reduced to a coherent local time truth. In the 1990s I found myself administering a campus network for a University--the only people less prepared than I as everybody else. A need arose to have a uniform notion of time across the campus (my recollection had to do with resolving who did it first squabbles as well as trying to solve some problems having to do with the date and time in emails regarding assignments due. I stumbled across NTP somewhere and decided that was the answer, I didn't know about "42" then. Nobody I was in contact with knew any more about it that I did, so I spent a lot of time on eecis learning how to make it play, and how not to be a rude participant. > > My template for NTP service deployment for any organization is very > simple: > > 1. Select four or more local systems and configure them as peer NTP > servers. In many instances one can leverage local DNS server > machines running almost any OS ? the NTP daemon runs on at least > Windows, OS X, UNIX, Linux. Don?t forget appropriate restrict > commands. I don't remember now how many boxes I had in my NTP backbone but it was lots--every cisco router I knew the password for (there were a lot of them, supporting frame-relay links to off-campus points), every HP9000 box I had root on, maybe the two Wellfleets -- I don't remember. They all were peers and I connected to a couple of off-network public stratum 1s and 2s not as peers (I had no budget for a stratum 0). > 2. Configure ntpd on the local servers to also select as servers a > list of 8-10 open access servers like pool.ntp.org, usno.navy.mil, > nist-????-ustiming.org. If you can arrange authenticated access to > other servers, that is possibly better. I tried, using "ping", to pick sturdy-sounding servers that were "close" to Omaha. > 3. As desired, configure ntpd on selected local servers for local > clocks or GPS clocks. This has little effect on accuracy, but may > enhance reliability. In many cases, it also requires building > penetrations for antennas. (Not easy for network guys.) > > 4. Configure all local time consumers to select from the list of > local NTP servers. Authenticate or not as you see fit. You can even > use DHCP to inform end systems of NTP server addresses. The router > folks will have to include NTP server addresses as part of each > configuration package. Did that. Told machines and people to use their default gateway address as their NTP (or SNTP) server. > Over the years I have successfully applied this template for NTP > service deployments to several large networks. It just works. It does. It does. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Mon Feb 10 01:08:26 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 09 Feb 2014 19:08:26 -0600 Subject: Need trusted NTP Sources In-Reply-To: References: <52F7EA22.5080805@cox.net> Message-ID: <52F8268A.6070503@cox.net> On 2/9/2014 7:04 PM, Larry Sheldon wrote: > In the 1990s I found myself administering a campus network for a > University--the only people less prepared than I as everybody else. In the 1990s I found myself administering a campus network for a University--the only people less prepared than I Was everybody else. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mike.williams at comodo.com Mon Feb 10 11:43:19 2014 From: mike.williams at comodo.com (Mike Williams) Date: Mon, 10 Feb 2014 11:43:19 +0000 Subject: GEO location issue with google In-Reply-To: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: <4835939.FJ4ILm3DhJ@mahdell> I've had similar trouble. Google thought we were in Israel, even months after filling in the form on the page Jonathan linked to, on several occasions. This was years after being allocated the address block by RIPE. We eventually got it sorted dead quick by implementing "Self-published IP Geolocation Data" and asking noc at google.com to use it. http://tools.ietf.org/html/draft-google-self-published-geofeeds-02 On Friday 07 February 2014 15:20:40 Praveen Unnikrishnan wrote: > Hi, > > We are an ISP based in UK. We have got an ip block from RIPE which is > 5.250.176.0/20. All the main search engines like yahoo shows we are based > in UK. But Google thinks we are from Saudi Arabia and we redirected to > www.google.com.sa instead of googlw.co.uk. I have > sent lot of emails to google but no luck. All the information from google > are in Arabic and youtube shows some weird videos as well. > > Could anyone please help me to sort this out? > > Would be much appreciated for your time. > > Praveen Unnikrishnan > Network Engineer > PMGC Technology Group Ltd > T: 020 3542 6401 > M: 07827921390 > F: 087 1813 1467 > E: piu at pmgroupuk.com > > [cid:image001.png at 01CF2418.27F29CA0] > > > [cid:image002.jpg at 01CE1663.96B300D0] > www.pmgroupuk.com | www.pmgchosting.com > How am I doing? Contact my manager, click > here. > > ________________________________ > [cid:image003.jpg at 01CE1663.96B300D0] > > PMGC Managed Hosting is now live! After a successful 2012, PMGC continues > to innovate and develop by offering tailored IT solutions designed to > empower you through intelligent use of technologies. > www.pmgchosting.com. > > PMGC Technology Group Limited is a company registered in England and Wales. > Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, > London. W1F 7TE). This message contains confidential (and potentially > legally privileged) information solely for its intended recipients. Others > may not distribute copy or use it. If you have received this communication > in error please contact the sender as soon as possible and delete the email > and any attachments without keeping copies. Any views or opinions presented > are solely those of the author and do not necessarily represent those of > the company or its associated companies unless otherwise specifically > stated. All incoming and outgoing e-mails may be monitored in line with > current legislation. It is the responsibility of the recipient to ensure > that emails are virus free before opening. > > PMGC(r) is a registered trademark of PMGC Technology Group Ltd. -- Mike Williams From pfsinoz at gmail.com Mon Feb 10 11:48:09 2014 From: pfsinoz at gmail.com (Philip Smith) Date: Mon, 10 Feb 2014 21:48:09 +1000 Subject: MENOG 14 in Dubai Message-ID: <52F8BC79.9030501@gmail.com> Hi everyone, In the spirit of keeping each of the NOG communities in touch with activities going on in each other's regions, the MENOG Program Committee is hoping that some of you would be interesting in joining the Middle East operations community for their 14th meeting in Dubai at the end of March. If you are interested in presenting at the conference or participating in the Peering Forum, or are planning to pass through Dubai enroute to other events, please consider submitting a presentation proposal: http://papers.menog.org/user/login.php?event=7 The programme committee is looking forward to your contributions; the submission deadline is just 2 weeks away now. MENOG 14 is being held at the Grosvenor House Hotel in Dubai Marina - the conference takes place on the 30th March, the MENOG Peering Forum on the 31st March, and tutorials are on 1st April. Workshops take place from 23rd to 27th March. More info at http://www.menog.org/meetings/menog-14. Thanks and hopefully see you in Dubai! philip (on behalf of the MENOG Coordination Team) -- From piu at pmgroupuk.com Mon Feb 10 12:59:05 2014 From: piu at pmgroupuk.com (Praveen Unnikrishnan) Date: Mon, 10 Feb 2014 12:59:05 +0000 Subject: GEO location issue with google In-Reply-To: References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: <1455bec81e1a4af7945bd6d728ce7946@DB3PR04MB026.eurprd04.prod.outlook.com> Hi Jonathan, I have been submitting this issue to google with that same reporting location issue page for last 4months. But it's still redirecting me to the different page.. :( Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: piu at pmgroupuk.com [cid:image004.png at 01CF265F.DD8E68C0] [cid:image002.jpg at 01CE1663.96B300D0] www.pmgroupuk.com | www.pmgchosting.com How am I doing? Contact my manager, click here. ________________________________ [cid:image003.jpg at 01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC(r) is a registered trademark of PMGC Technology Group Ltd. From: Jonathan Lassoff [mailto:jof at thejof.com] Sent: 08 February 2014 06:36 To: Praveen Unnikrishnan Cc: nanog at nanog.org Subject: Re: GEO location issue with google Here's the FAQ on this topic: https://support.google.com/websearch/answer/873?hl=en It links to a contact form where you can ask for some redress. Cheers, jof On Fri, Feb 7, 2014 at 7:20 AM, Praveen Unnikrishnan > wrote: Hi, We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. Could anyone please help me to sort this out? Would be much appreciated for your time. Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: piu at pmgroupuk.com> [cid:image001.png at 01CF2418.27F29CA0] [cid:image002.jpg at 01CE1663.96B300D0] www.pmgroupuk.com | www.pmgchosting.com How am I doing? Contact my manager, click here?subject=How's%20Praveen%20doing?>. ________________________________ [cid:image003.jpg at 01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC(r) is a registered trademark of PMGC Technology Group Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6879 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 14829 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 184 bytes Desc: image004.png URL: From chris at aperturefiber.com Mon Feb 10 13:11:59 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Mon, 10 Feb 2014 07:11:59 -0600 Subject: GEO location issue with google In-Reply-To: <1455bec81e1a4af7945bd6d728ce7946@DB3PR04MB026.eurprd04.prod.outlook.com> References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> <1455bec81e1a4af7945bd6d728ce7946@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: I have had my best luck with getting google to correct geo-loc issues by sending it in as a business end user instead of as an ISP. If you have a user who is being affected directly by the incorrect geo-loc data (My store is showing in the wrong country), Google takes that much more seriously than the issue affecting dynamically assigned blocks. Need coffee?perhaps unclear. Message me off list and I can explain a little better. On Feb 10, 2014, at 6:59 AM, Praveen Unnikrishnan wrote: > Hi Jonathan, > > I have been submitting this issue to google with that same reporting location issue page for last 4months. But it's still redirecting me to the different page.. :( > > Praveen Unnikrishnan > Network Engineer > PMGC Technology Group Ltd > T: 020 3542 6401 > M: 07827921390 > F: 087 1813 1467 > E: piu at pmgroupuk.com > > [cid:image004.png at 01CF265F.DD8E68C0] > > > [cid:image002.jpg at 01CE1663.96B300D0] > www.pmgroupuk.com | www.pmgchosting.com > How am I doing? Contact my manager, click here. > > ________________________________ > [cid:image003.jpg at 01CE1663.96B300D0] > > PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. > > PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. > > PMGC(r) is a registered trademark of PMGC Technology Group Ltd. > > > From: Jonathan Lassoff [mailto:jof at thejof.com] > Sent: 08 February 2014 06:36 > To: Praveen Unnikrishnan > Cc: nanog at nanog.org > Subject: Re: GEO location issue with google > > Here's the FAQ on this topic: https://support.google.com/websearch/answer/873?hl=en > > It links to a contact form where you can ask for some redress. > > Cheers, > jof > > On Fri, Feb 7, 2014 at 7:20 AM, Praveen Unnikrishnan > wrote: > Hi, > > We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. > > Could anyone please help me to sort this out? > > Would be much appreciated for your time. > > Praveen Unnikrishnan > Network Engineer > PMGC Technology Group Ltd > T: 020 3542 6401 > M: 07827921390 > F: 087 1813 1467 > E: piu at pmgroupuk.com> > > [cid:image001.png at 01CF2418.27F29CA0] > > > [cid:image002.jpg at 01CE1663.96B300D0] > www.pmgroupuk.com | www.pmgchosting.com > How am I doing? Contact my manager, click here?subject=How's%20Praveen%20doing?>. > > ________________________________ > [cid:image003.jpg at 01CE1663.96B300D0] > > PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. > > PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. > > PMGC(r) is a registered trademark of PMGC Technology Group Ltd. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jcurran at arin.net Mon Feb 10 14:48:48 2014 From: jcurran at arin.net (John Curran) Date: Mon, 10 Feb 2014 14:48:48 +0000 Subject: ARIN PPC Agenda for NANOG 60 Tuesday AM session Now Available References: <52F13A98.40602@arin.net> Message-ID: NANOG 60 Attendees - Tomorrow morning there will be a Public Policy Consultation regarding a sizable number of potential changes to address policy at ARIN. Please find attached the list of policy proposals to be discussed; the session begins at 9:30 AM and all attendees are welcome! Text of each proposed changes is available at: https://www.arin.net/policy/proposals/ There is also a PPC Discussion Guide available with all of the draft policies, the ARIN policy development process, and the current policy manual available here: https://www.arin.net/ppcnanog60 Thank you, and look forward to seeing everyone tomorrow! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN PPC Agenda for NANOG 60 Now Available Date: February 4, 2014 at 2:08:08 PM EST To: arin-announce at arin.net Don't forget to mark your calendar and join us for ARIN's Public Policy Consultation (PPC), which will be held during NANOG 60 in Atlanta, Georgia on Tuesday, 11 February 2014, from 9:30 - 1:00 PM. The policy consultation is part of ARIN's Policy Development Process, and it is an open public discussion of Internet number resource policy. Registered NANOG 60 attendees do not need to register to participate in this session. ARIN welcomes members of the NANOG community who will not be in Atlanta to register as remote participants. If you plan to attend and are not registered for NANOG you must register for the ARIN PPC at the https://www.arin.net/ppcregister There is no registration fee for this half-day ARIN session, and it does not provide you entry to any other NANOG programming or social events. Current policy proposals up for discussion at this meeting are: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup Draft Policy ARIN-2014-1: Out of Region Use Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Draft Policy ARIN-2014-6: Remove 7.1 (Maintaining IN-ADDRs) Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update Proposals (193, 199 and 201) That first item is a Recommended Draft Policy; the ARIN Advisory Council recommends it as fair and technically sound policy. The Drafts and Proposals are works in progress. Text available at: https://www.arin.net/policy/proposals/ or in the PPC Discussion Guide: https://www.arin.net/ppcnanog60 ARIN will offer a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants can submit comments and questions to the discussions during the meeting. Register to attend in person or remotely today! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From vristevs at ramapo.edu Mon Feb 10 15:17:09 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Mon, 10 Feb 2014 10:17:09 -0500 Subject: 7206 VXR NPE-G1 throughput Message-ID: <52F8ED75.2090200@ramapo.edu> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: 30 second input rate 559982000 bits/sec, 55809 packets/sec 30 second output rate 55429000 bits/sec, 32598 packets/sec 267756984712 packets input, 333325152556755 bytes, 0 no buffer This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. Answers on and off list are appreciated. Thanks, -- Vlad From remco at signet.nl Mon Feb 10 15:30:50 2014 From: remco at signet.nl (Remco Bressers) Date: Mon, 10 Feb 2014 16:30:50 +0100 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8ED75.2090200@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> Message-ID: <52F8F0AA.4060302@signet.nl> On 02/10/2014 04:17 PM, Vlade Ristevski wrote: > We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few > people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. > The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: > > > 30 second input rate 559982000 bits/sec, 55809 packets/sec > 30 second output rate 55429000 bits/sec, 32598 packets/sec > 267756984712 packets input, 333325152556755 bytes, 0 no buffer > > This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. Regards, Remco Bressers Signet B.V. From ahebert at pubnix.net Mon Feb 10 15:40:04 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 10 Feb 2014 10:40:04 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F0AA.4060302@signet.nl> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> Message-ID: <52F8F2D4.8020904@pubnix.net> I have one but I never ran that much BW thru mine. But the CPU usage is what will kill you. Also the entire platform is rate for 1.8Gbs aggregated which mean depending on which interface you have, and which bus they are connected to, 900Mbps might be its limit. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/10/14 10:30, Remco Bressers wrote: > On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few >> people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >> >> >> 30 second input rate 559982000 bits/sec, 55809 packets/sec >> 30 second output rate 55429000 bits/sec, 32598 packets/sec >> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >> >> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. > This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased > our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. > > Regards, > > Remco Bressers > Signet B.V. > > > > > From joelja at bogus.com Mon Feb 10 15:41:18 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 10 Feb 2014 07:41:18 -0800 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8ED75.2090200@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> Message-ID: <52F8F31E.6030704@bogus.com> On 2/10/14, 7:17 AM, Vlade Ristevski wrote: > We are looking to double the bandwidth on one of our circuits from > 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 > card. These seem like very popular routers so I'm hoping a few people on > this list have them deployed. If you or a customer have these deployed, > how much bandwidth have you seen them handle? This will be handling dorm > traffic at a college so it's mostly download. The 7206 handles our 300 > Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At > peak we've seen the following numbers for that circuit: > > > 30 second input rate 559982000 bits/sec, 55809 packets/sec > 30 second output rate 55429000 bits/sec, 32598 packets/sec > 267756984712 packets input, 333325152556755 bytes, 0 no buffer > > This is the interface that connects to our provider. As you can see its > almost all download traffic. Our ASR1002 handles it without a sweat but > I'm a little skeptical of whether the 7206 will hold up. I wouldn't expect a g1 to do much more than half a gig... https://supportforums.cisco.com/servlet/JiveServlet/download/561469-9512/routerperformance.pdf > Answers on and off list are appreciated. > > Thanks, > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From vristevs at ramapo.edu Mon Feb 10 15:43:04 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Mon, 10 Feb 2014 10:43:04 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F0AA.4060302@signet.nl> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> Message-ID: <52F8F388.6030301@ramapo.edu> We're still on the 12.4 train. I do use an ACL with less than 100 entries which handle BCP38 and block a few bad actors and private IPs on the Internet. I will be moving the BCP38 ACL closer to the hosts before the upgrade so the ACL will be a bit shorter in the future. We won't be doing any QOS or IPv6 on it but it does take a full BGP table. I just need it to last another year or two out of it if possible. I believe this platform goes End of Support in Spring 2016. On 2/10/2014 10:30 AM, Remco Bressers wrote: > On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few >> people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >> >> >> 30 second input rate 559982000 bits/sec, 55809 packets/sec >> 30 second output rate 55429000 bits/sec, 32598 packets/sec >> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >> >> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. > This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased > our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. > > Regards, > > Remco Bressers > Signet B.V. > > > -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 From vristevs at ramapo.edu Mon Feb 10 15:47:25 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Mon, 10 Feb 2014 10:47:25 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F2D4.8020904@pubnix.net> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F2D4.8020904@pubnix.net> Message-ID: <52F8F48D.8050108@ramapo.edu> Both the inside and outside interfaces are on the same NPE-G1 card. Thanks, On 2/10/2014 10:40 AM, Alain Hebert wrote: > I have one but I never ran that much BW thru mine. > > But the CPU usage is what will kill you. > > Also the entire platform is rate for 1.8Gbs aggregated which mean > depending on which interface you have, and which bus they are connected > to, 900Mbps might be its limit. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 02/10/14 10:30, Remco Bressers wrote: >> On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >>> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few >>> people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >>> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >>> >>> >>> 30 second input rate 559982000 bits/sec, 55809 packets/sec >>> 30 second output rate 55429000 bits/sec, 32598 packets/sec >>> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >>> >>> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. >> This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased >> our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. >> >> Regards, >> >> Remco Bressers >> Signet B.V. >> >> >> >> >> > -- Vlad From remco at signet.nl Mon Feb 10 15:55:34 2014 From: remco at signet.nl (Remco Bressers) Date: Mon, 10 Feb 2014 16:55:34 +0100 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F388.6030301@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> Message-ID: <52F8F676.4@signet.nl> On 02/10/2014 04:43 PM, Vlade Ristevski wrote: > We're still on the 12.4 train. I do use an ACL with less than 100 entries which handle BCP38 and block a few bad actors and private IPs on the Internet. I will be moving the BCP38 ACL closer to the > hosts before the upgrade so the ACL will be a bit shorter in the future. We won't be doing any QOS or IPv6 on it but it does take a full BGP table. I just need it to last another year or two out of it > if possible. I believe this platform goes End of Support in Spring 2016. > > > On 2/10/2014 10:30 AM, Remco Bressers wrote: >> On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >>> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few >>> people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >>> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >>> >>> >>> 30 second input rate 559982000 bits/sec, 55809 packets/sec >>> 30 second output rate 55429000 bits/sec, 32598 packets/sec >>> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >>> >>> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. >> This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased >> our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. Full routing and ACL 100+ entries? I would ditch the 7200+NPE-G1 or upgrade to an NPE-G2.. Regards, Remco Bressers Signet B.V. From vristevs at ramapo.edu Mon Feb 10 15:57:46 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Mon, 10 Feb 2014 10:57:46 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F31E.6030704@bogus.com> References: <52F8ED75.2090200@ramapo.edu> <52F8F31E.6030704@bogus.com> Message-ID: <52F8F6FA.5010709@ramapo.edu> Thanks for the link. When I looked at it, the PPS and bandwidth didn't really match what I see on my network so I'm curious to see what people are actually seeing. It looks like their test is done using very small packets (64K). Our traffic is mostly web with a lot of Video (netflix , Hulu, youtube, Flash etc) so we're dealing with a lot less packets that are much larger. Based on the numbers I posted, we' would be at the BW limit without even coming close the PPS limit (if we were running the traffic through the 7206). On 2/10/2014 10:41 AM, joel jaeggli wrote: > On 2/10/14, 7:17 AM, Vlade Ristevski wrote: >> We are looking to double the bandwidth on one of our circuits from >> 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 >> card. These seem like very popular routers so I'm hoping a few people on >> this list have them deployed. If you or a customer have these deployed, >> how much bandwidth have you seen them handle? This will be handling dorm >> traffic at a college so it's mostly download. The 7206 handles our 300 >> Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At >> peak we've seen the following numbers for that circuit: >> >> >> 30 second input rate 559982000 bits/sec, 55809 packets/sec >> 30 second output rate 55429000 bits/sec, 32598 packets/sec >> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >> >> This is the interface that connects to our provider. As you can see its >> almost all download traffic. Our ASR1002 handles it without a sweat but >> I'm a little skeptical of whether the 7206 will hold up. > I wouldn't expect a g1 to do much more than half a gig... > > https://supportforums.cisco.com/servlet/JiveServlet/download/561469-9512/routerperformance.pdf > >> Answers on and off list are appreciated. >> >> Thanks, >> >> > -- Vlad From vristevs at ramapo.edu Mon Feb 10 16:05:33 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Mon, 10 Feb 2014 11:05:33 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F676.4@signet.nl> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> Message-ID: <52F8F8CD.6090808@ramapo.edu> The ACL is a recent addition and we can probably do away with it. I didn't notice a significant increase in CPU or drops since adding it. But we usually peak at about 200Mbps on this link. The full routing table is a must since we're dual homed. On 2/10/2014 10:55 AM, Remco Bressers wrote: > On 02/10/2014 04:43 PM, Vlade Ristevski wrote: >> We're still on the 12.4 train. I do use an ACL with less than 100 entries which handle BCP38 and block a few bad actors and private IPs on the Internet. I will be moving the BCP38 ACL closer to the >> hosts before the upgrade so the ACL will be a bit shorter in the future. We won't be doing any QOS or IPv6 on it but it does take a full BGP table. I just need it to last another year or two out of it >> if possible. I believe this platform goes End of Support in Spring 2016. >> >> >> On 2/10/2014 10:30 AM, Remco Bressers wrote: >>> On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >>>> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few >>>> people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >>>> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >>>> >>>> >>>> 30 second input rate 559982000 bits/sec, 55809 packets/sec >>>> 30 second output rate 55429000 bits/sec, 32598 packets/sec >>>> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >>>> >>>> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. >>> This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased >>> our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. > > Full routing and ACL 100+ entries? I would ditch the 7200+NPE-G1 or upgrade to an NPE-G2.. > > Regards, > > Remco Bressers > Signet B.V. > > -- Vlad From nchabbey at n3network.ch Mon Feb 10 16:08:42 2014 From: nchabbey at n3network.ch (Nicolas Chabbey) Date: Mon, 10 Feb 2014 17:08:42 +0100 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F0AA.4060302@signet.nl> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> Message-ID: <52F8F98A.3080405@n3network.ch> On 02/10/2014 04:30 PM, Remco Bressers wrote: > On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >> We are looking to double the bandwidth on one of our circuits from 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few >> people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >> >> >> 30 second input rate 559982000 bits/sec, 55809 packets/sec >> 30 second output rate 55429000 bits/sec, 32598 packets/sec >> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >> >> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. > > This depends on multiple variables. The 7200 is a single-CPU platform where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased > our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. > I do share the same thoughts as Remco. We've actually several NPE-G1 in production environments with full BGP feed. We saw a decrease in forwarding performance since 12.4T and up. We also recently disabled some features like netflow and ip inspection, which seemed relatively CPU intensive. I do remember we were able to forward around ~700Mbps of 1500 bytes traffic with old IOS images and no ACLs. From joelja at bogus.com Mon Feb 10 16:07:17 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 10 Feb 2014 08:07:17 -0800 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F388.6030301@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> Message-ID: <52F8F935.7060406@bogus.com> On 2/10/14, 7:43 AM, Vlade Ristevski wrote: > We're still on the 12.4 train. I do use an ACL with less than 100 > entries which handle BCP38 and block a few bad actors and private IPs on > the Internet. I will be moving the BCP38 ACL closer to the hosts before > the upgrade so the ACL will be a bit shorter in the future. We won't be > doing any QOS or IPv6 on it but it does take a full BGP table. I just > need it to last another year or two out of it if possible. I believe > this platform goes End of Support in Spring 2016. yeah so you'll probably make it on a pure pps basis. > > On 2/10/2014 10:30 AM, Remco Bressers wrote: >> On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >>> We are looking to double the bandwidth on one of our circuits from >>> 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 >>> card. These seem like very popular routers so I'm hoping a few >>> people on this list have them deployed. If you or a customer have >>> these deployed, how much bandwidth have you seen them handle? This >>> will be handling dorm traffic at a college so it's mostly download. >>> The 7206 handles our 300 Mbps circuit just fine, but we are moving it >>> to our 600Mbps circuit. At peak we've seen the following numbers for >>> that circuit: >>> >>> >>> 30 second input rate 559982000 bits/sec, 55809 packets/sec >>> 30 second output rate 55429000 bits/sec, 32598 packets/sec >>> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >>> >>> This is the interface that connects to our provider. As you can see >>> its almost all download traffic. Our ASR1002 handles it without a >>> sweat but I'm a little skeptical of whether the 7206 will hold up. >> This depends on multiple variables. The 7200 is a single-CPU platform >> where CPU can go sky-high when using features like ACL's, QoS, IPv6 >> and you name it.. Also, changing from IOS 12.4 to 15 increased >> our CPU usage with another 10%+. Stick to the bare minimum of features >> you really need and you will be fine. >> >> Regards, >> >> Remco Bressers >> Signet B.V. >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From joe at breathe-underwater.com Mon Feb 10 17:08:49 2014 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Mon, 10 Feb 2014 09:08:49 -0800 Subject: Looking for some guidance on creating route objects for ARIN Message-ID: I am trying to get the routing objects database. However I am getting back failures for the messages that I send in. I am wondering is it possible to get route objects created for the two /24s that I was given from my carriers allocations? If so what is the process to update the route objects database? I have my MNTNERID for my company, but when I use that to try and update the objects and attach them to my AS I am getting a failure. TIA Joe Jenkins From joelja at bogus.com Mon Feb 10 17:12:50 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 10 Feb 2014 09:12:50 -0800 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F6FA.5010709@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F31E.6030704@bogus.com> <52F8F6FA.5010709@ramapo.edu> Message-ID: <52F90892.90201@bogus.com> On 2/10/14, 7:57 AM, Vlade Ristevski wrote: > Thanks for the link. When I looked at it, the PPS and bandwidth didn't > really match what I see on my network so I'm curious to see what people > are actually seeing. It looks like their test is done using very small > packets (64K). Our traffic is mostly web with a lot of Video (netflix , > Hulu, youtube, Flash etc) so we're dealing with a lot less packets that > are much larger. Based on the numbers I posted, we' would be at the BW > limit without even coming close the PPS limit (if we were running the > traffic through the 7206). so those pps numbers are worst case (small packet) but the acl count /distribution and so on are going to impact what you actually get in the downward direction. > > On 2/10/2014 10:41 AM, joel jaeggli wrote: >> On 2/10/14, 7:17 AM, Vlade Ristevski wrote: >>> We are looking to double the bandwidth on one of our circuits from >>> 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 >>> card. These seem like very popular routers so I'm hoping a few people on >>> this list have them deployed. If you or a customer have these deployed, >>> how much bandwidth have you seen them handle? This will be handling dorm >>> traffic at a college so it's mostly download. The 7206 handles our 300 >>> Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At >>> peak we've seen the following numbers for that circuit: >>> >>> >>> 30 second input rate 559982000 bits/sec, 55809 packets/sec >>> 30 second output rate 55429000 bits/sec, 32598 packets/sec >>> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >>> >>> This is the interface that connects to our provider. As you can see its >>> almost all download traffic. Our ASR1002 handles it without a sweat but >>> I'm a little skeptical of whether the 7206 will hold up. >> I wouldn't expect a g1 to do much more than half a gig... >> >> https://supportforums.cisco.com/servlet/JiveServlet/download/561469-9512/routerperformance.pdf >> >> >>> Answers on and off list are appreciated. >>> >>> Thanks, >>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From JPSchneider at netins.com Mon Feb 10 17:24:44 2014 From: JPSchneider at netins.com (John P. Schneider) Date: Mon, 10 Feb 2014 17:24:44 +0000 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F676.4@signet.nl> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> Message-ID: <5567B54E91CCB04786326375E6DA9BCB836152E8@dtnmailbox.iowanetworkservices.net> 600Mb is going to be really pushing it. I doubt it will be able to handle that kind of throughput. Even with G2 I would think you would be pushing it. -----Original Message----- From: Remco Bressers [mailto:remco at signet.nl] Sent: Monday, February 10, 2014 9:56 AM To: nanog at nanog.org Subject: Re: 7206 VXR NPE-G1 throughput On 02/10/2014 04:43 PM, Vlade Ristevski wrote: > We're still on the 12.4 train. I do use an ACL with less than 100 > entries which handle BCP38 and block a few bad actors and private IPs > on the Internet. I will be moving the BCP38 ACL closer to the hosts before the upgrade so the ACL will be a bit shorter in the future. We won't be doing any QOS or IPv6 on it but it does take a full BGP table. I just need it to last another year or two out of it if possible. I believe this platform goes End of Support in Spring 2016. > > > On 2/10/2014 10:30 AM, Remco Bressers wrote: >> On 02/10/2014 04:17 PM, Vlade Ristevski wrote: >>> We are looking to double the bandwidth on one of our circuits from >>> 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like very popular routers so I'm hoping a few people on this list have them deployed. If you or a customer have these deployed, how much bandwidth have you seen them handle? This will be handling dorm traffic at a college so it's mostly download. >>> The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 600Mbps circuit. At peak we've seen the following numbers for that circuit: >>> >>> >>> 30 second input rate 559982000 bits/sec, 55809 packets/sec >>> 30 second output rate 55429000 bits/sec, 32598 packets/sec >>> 267756984712 packets input, 333325152556755 bytes, 0 no buffer >>> >>> This is the interface that connects to our provider. As you can see its almost all download traffic. Our ASR1002 handles it without a sweat but I'm a little skeptical of whether the 7206 will hold up. >> This depends on multiple variables. The 7200 is a single-CPU platform >> where CPU can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. Also, changing from IOS 12.4 to 15 increased our CPU usage with another 10%+. Stick to the bare minimum of features you really need and you will be fine. Full routing and ACL 100+ entries? I would ditch the 7200+NPE-G1 or upgrade to an NPE-G2.. Regards, Remco Bressers Signet B.V. From nick at foobar.org Mon Feb 10 17:58:16 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Feb 2014 17:58:16 +0000 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F0AA.4060302@signet.nl> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> Message-ID: <52F91338.104@foobar.org> On 10/02/2014 15:30, Remco Bressers wrote: > This depends on multiple variables. The 7200 is a single-CPU platform > where CPU can go sky-high when using features like ACL's, QoS, IPv6 and > you name it.. Also, changing from IOS 12.4 to 15 increased our CPU usage > with another 10%+. Stick to the bare minimum of features you really need > and you will be fine. in fact, the npe-g1 uses a BCM1250 which is a dual CPU unit but vanilla IOS is not able to use the second CPU for packet forwarding. Unsubstantiated rumour claimed that modular IOS (QNX kernel) could push about 1.6x the throughput of vanilla IOS, as it was smp capable. Pity it was never released. Nick From alvarezp at alvarezp.ods.org Mon Feb 10 18:27:34 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 10 Feb 2014 10:27:34 -0800 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F8CD.6090808@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> Message-ID: <52F91A16.4080100@alvarezp.ods.org> On 02/10/2014 08:05 AM, Vlade Ristevski wrote: > The ACL is a recent addition and we can probably do away with it. I > didn't notice a significant increase in CPU or drops since adding it. > But we usually peak at about 200Mbps on this link. The full routing > table is a must since we're dual homed. You don't necessarily need the full routing table for dual home, only for outgoing load balance. You can have BGP, filter your routes away, just leave a default gateway and still have dual homing. Your outgoing traffic will work as if it were active-standby, though. My 0.02. From kemp at network-services.uoregon.edu Mon Feb 10 19:30:58 2014 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 10 Feb 2014 11:30:58 -0800 Subject: cert's routeviews mirror Message-ID: <52F928F2.8000306@network-services.uoregon.edu> Someone asked me for the link... http://routeviews-mirror.cert.org/ John Kemp help at routeviews.org From jay at west.net Mon Feb 10 19:43:02 2014 From: jay at west.net (Jay Hennigan) Date: Mon, 10 Feb 2014 11:43:02 -0800 Subject: Looking for some guidance on creating route objects for ARIN In-Reply-To: References: Message-ID: <52F92BC6.5070607@west.net> On 2/10/14 9:08 AM, Joseph Jenkins wrote: > I am trying to get the routing objects database. However I am getting back failures for the messages that I send in. I am wondering is it possible to get route objects created for the two /24s that I was given from my carriers allocations? If so what is the process to update the route objects database? I have my MNTNERID for my company, but when I use that to try and update the objects and attach them to my AS I am getting a failure. What are you sending (passwords redacted), to whom, and what failure message are you receiving? -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From shopik at inblock.ru Mon Feb 10 19:44:17 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Mon, 10 Feb 2014 23:44:17 +0400 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F91338.104@foobar.org> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F91338.104@foobar.org> Message-ID: <52F92C11.40608@inblock.ru> On 10.02.2014 21:58, Nick Hilliard wrote: > Unsubstantiated > rumour claimed that modular IOS (QNX kernel) could push about 1.6x the > throughput of vanilla IOS, as it was smp capable. Pity it was never released. You mean IOS XR? Which was never released for software based routers, right? as it QNX in core. From mark.tinka at seacom.mu Mon Feb 10 20:31:16 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Feb 2014 22:31:16 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8ED75.2090200@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> Message-ID: <201402102231.17258.mark.tinka@seacom.mu> On Monday, February 10, 2014 05:17:09 PM Vlade Ristevski wrote: > This is the interface that connects to our provider. As > you can see its almost all download traffic. Our ASR1002 > handles it without a sweat but I'm a little skeptical of > whether the 7206 will hold up. An NPE-G2 has a better chance of handling 600Mbps. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Feb 10 20:32:33 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Feb 2014 22:32:33 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F2D4.8020904@pubnix.net> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F2D4.8020904@pubnix.net> Message-ID: <201402102232.34352.mark.tinka@seacom.mu> On Monday, February 10, 2014 05:40:04 PM Alain Hebert wrote: > Also the entire platform is rate for 1.8Gbs > aggregated which mean depending on which interface you > have, and which bus they are connected to, 900Mbps might > be its limit. I've done 900Mbps on an NPE-G2 with 95% CPU utilization and no packet drops, in a core router role. An NPE-G1 won't do that. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From job.snijders at hibernianetworks.com Mon Feb 10 20:33:21 2014 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Mon, 10 Feb 2014 15:33:21 -0500 Subject: selective blackholing: implementation, usage & effectiveness Message-ID: <20140210203321.GG21911@Eleanor.local> Dear fellow networkers, Through this tutorial-styled email I'd like to introduce the concept, usage and implementation of "selective blackholing" through the BGP protocol to the community. This email contains some python code, example router configurations references to RIPE Atlas data to demonstrate effectiveness. Selective Blackholing is a DDoS damage control mechanism which is (compared to scrubbing or conventional blackholing) cheaper and more effective from the perspective of both the Service Provider and the End-User. In today's internet DDoS attacks are common-place, and the balance is not particularly fair: very expensive on the receiver-side and very cheap for the evil-doer (think DNS-, NTP- and SNMP-amplification attacks). I propose a method which is effective for businesses with a scoped radius of interaction with their customers. To elaborate on what 'scoped' (read: selective) means: a Dutch herring-shop owner will see most legitimate visitors come from within the Netherlands; a Dallas, TX based Automotive Bulletin Board will see most conversions from visitor to part-buyer come from visitors within the United States. If we look at today's DDoS mitigation solutions (scrubbers: expensive hardware or subscription services, or BGP blackhole: all or nothing reachability)... it seems intuitive that a lot of business-owners would care more about traffic from visitors in the surrounding 1000 kilometers (or from the same country), than say (for the duration of the attack) traffic sourced from other continents. In this document we sequentially number any line of router config or python code, to allow for easy references. Let's focus on the implementation following four features: * discard traffic sourced outside 'this' country (5580:664) * discard traffic sourced outside 'this' continent (5580:660) * discard traffic sourced outside a 1000 km radius from 'here' (5580:663) * discard traffic sourced outside a 2500 km radius from 'here' (5580:662) The 'this' and 'here' designators refer to the point of interconnection with any given customer: 'this' and 'here' for a customer connecting to AS5580 in Amsterdam, would respectable be "Netherlands, Europe, 'most of West Europe', 'most of West + Central Europe'". It is important to understand that all proposed mechanisms are designed to perform uniformly in terms of intended usage regardless of location of interconnection, so for a Dutch customer 5580:664 means 'discard any traffic for my prefix received on PEs outside the Netherlands' but for an Dallas, TX based customer BGP community '5580:663' would mean 'discard traffic destined to my prefix on routers located outside a 1000 km radius around Dallas'. The 1000 km and 2500 km distances referenced throughout this document mean the distance between AS 5580 network devices as calculated with a haversine formula with the GPS coordinates of devices as input. The haversine formula is an equation giving great-circle distances between two points on a sphere from their longitudes and latitudes. Actual length of datapath or optical paths is not taken into consideration, nor is a peering partner's home country a factor. To create the above described features we need a simplistic CMDB database, some python code, static inbound iBGP route-map and semi-dynamic customer facing inbound route-map. For illustration purposes we assume a fictional ISP with a POP in the following cities: Tokyo, San Jose, Dallas, New York, London, Amsterdam and Stockholm. +-----------+-----------+----------+-------+---------------------+ | router | continent | country | metro | latitude, longitude | | name | id | ISO31661 | id | | +-----------+-----------+----------+-------+---------------------+ | r1.tky.jp | 3 | 392 | 46 | 35.65671, 139.80342 | | r1.sjo.us | 1 | 840 | 29 | 37.44569,-122.16111 | | r1.dal.us | 1 | 840 | 33 | 32.80096, -96.81962 | | r1.nyc.us | 1 | 840 | 26 | 40.71780, -74.00885 | | r1.lon.uk | 2 | 276 | 23 | 51.51173, -0.00197 | | r1.ams.nl | 2 | 528 | 20 | 52.35600, 4.95068 | | r1.sto.se | 2 | 752 | 22 | 59.36264, 17.95560 | +-----------+-----------+----------+-------+---------------------+ Table 1. Simplistic CMDB Based on the above CMDB table we can construct the following device specific configuration snippets. Within these snippets we adhere to the concept that edge devices are smart and core devices dumb. At the edge of the network we accept BGP Communities from customers, which we translate through a process of testing & branching from 'something the customer understands' to 'something the network understands'. r1.tky.jp: 001. ip community-list THIS:METRO seq 5 permit 65123:30046 002. ip community-list THIS:COUNTRY seq 5 permit 65123:392 003. ip community-list THIS:CONTINENT seq 5 permit 65123:3000 r1.sjo.us: 004. ip community-list THIS:METRO seq 5 permit 65123:10029 005. ip community-list THIS:COUNTRY seq 5 permit 65123:840 006. ip community-list THIS:CONTINENT seq 5 permit 65123:1000 r1.dal.us: 007. ip community-list THIS:METRO seq 5 permit 65123:10033 008. ip community-list THIS:COUNTRY seq 5 permit 65123:840 009. ip community-list THIS:CONTINENT seq 5 permit 65123:1000 r1.nyc.us: 010. ip community-list THIS:METRO seq 5 permit 65123:10026 011. ip community-list THIS:COUNTRY seq 5 permit 65123:840 012. ip community-list THIS:CONTINENT seq 5 permit 65123:1000 r1.lon.uk: 013. ip community-list THIS:METRO seq 5 permit 65123:20023 014. ip community-list THIS:COUNTRY seq 5 permit 65123:276 015. ip community-list THIS:CONTINENT seq 5 permit 65123:2000 r1.ams.nl: 016. ip community-list THIS:METRO seq 5 permit 65123:20020 017. ip community-list THIS:COUNTRY seq 5 permit 65123:528 018. ip community-list THIS:CONTINENT seq 5 permit 65123:2000 r1.sto.us: 019. ip community-list THIS:METRO seq 5 permit 65123:20022 020. ip community-list THIS:COUNTRY seq 5 permit 65123:725 021. ip community-list THIS:CONTINENT seq 5 permit 65123:2000 all devices (common references for more humane route-map definitions): 022. ! communities which are exposed in public documentation for customers 023. ip community-list OUTSIDE:THIS:CONTINENT:DISCARD seq 5 permit 5580:660 024. ip community-list OUTSIDE:2500KM:RADIUS:DISCARD seq 5 permit 5580:662 025. ip community-list OUTSIDE:1000KM:RADIUS:DISCARD seq 5 permit 5580:663 026. ip community-list OUTSIDE:THIS:COUNTRY:DISCARD seq 5 permit 5580:664 027. ip community-list GLOBAL:BLACKHOLE seq 5 permit 5580:666 028. ip community-list SCOPED:ACTION seq 5 permit 5580:660 029. ip community-list SCOPED:ACTION seq 5 permit 5580:662 030. ip community-list SCOPED:ACTION seq 5 permit 5580:663 031. ip community-list SCOPED:ACTION seq 5 permit 5580:664 032. ip route 10.0.0.1/32 null0 all devices (static inbound iBGP route-map): 033. route-map RX:iBGP permit 100 034. match community GLOBAL:BLACKHOLE 035. continue 1100 036. route-map RX:iBGP permit 100 037. match community OUTSIDE:THIS:COUNTRY:DISCARD OUTSIDE:THIS:CONTINENT:DISCARD 038. continue 1100 039. route-map RX:iBGP permit 110 040. match community OUTSIDE:1000KM:RADIUS:DISCARD OUTSIDE:2500KM:RADIUS:DISCARD 041. continue 1100 042. route-map RX:iBGP permit 1000 043 route-map RX:iBGP permit 1100 044. match community THIS:METRO THIS:COUNTRY THIS:CONTINENT 045. route-map RX:iBGP permit 1101 046. set community no-export additive 047. set ip next-hop 10.0.0.1 048. set local-preference 1000000 The above route-map allows BGP speakers in our routing domain to apply different actions depending on the (geographically significant) communities. Let's use three example input and run them through the route-map to illustrate what happens: evaluation takes place on: router r1.lon.uk input: communities: none result: prefix accepted without modifications why: The first match is 'permit 1000' at line 042, because there is no match statement all prefixes will be accepted and the route-map is not evaulated any further. evaluation takes place on: router r1.lon.uk input: communities: "5580:662 65123:10033 65123:10029" (for example when a customer attached to r1.sjo.us sets "5580:662 - discard outside 2500km") result: traffic for the prefix will be discarded why: The prefix matches with the clause 110 (line 039) because 5580:662 matches OUTSIDE:2500KM:RADIUS:DISCARD (line 040). Because a match is found on line 041 we jump to line 043 for further matching. Because the community string cannot match any of the communities on line 044 (in the case of r1.lon.uk 65123:20023 OR 65123:276 OR 65123:2000), the prefix is further evaluated at line 045. There is no match statement in the 'permit 1101' clause so for any prefix that arrives at this particular clause in the route-map the next-hop will be 10.0.0.1 (discard). Because the prefix matches with clause 1101 the route-map will not be evaluated any further. evaluation takes place on: router r1.dal.us input: communities: "5580:662 65123:10033 65123:10029" (for example when a customer attached to r1.sjo.us sets "5580:662 - discard outside 2500km") result: prefix will be accepted with no further modifications why: The prefix matches with the clause 110 (line 039) because 5580:662 matches OUTSIDE:2500KM:RADIUS:DISCARD (line 040). Because a match is found, the continue statement (line 041) is followed and we jump to line 043 for further matching. Because the community string matches one of the communities on line 044 (in the case of r1.dal.us 65123:10033 OR 65123:840 OR 65123:1000), further evaluation of the route-map is halted, and the clause which actually makes it a blackhole is never reached. The attentive reader will now probably think "How come you are inputting "5580:662 65123:10033 65123:10029", and not just 5580:662?! You promised simple end-user configuration, no customer will want to invest time to figure out magic values such as 65123:10033 65123:10029! Now we get down the the secret sauce: extensive community rewriting.... Based on our CMDB database, we can calculate sets of magic values that will cause the network to behave according to the desired feature. I've made a sample python program available that will do these calculations. This is the output: 049. Eleanor:~ job$ wget -q http://noc.as5580.net/~job/example_community_calculator.py 050. Eleanor:~ job$ python example_community_calculator.py 051. r1.lon.uk - rewrite targets: 052. 1000 km: 65123:20020 65123:276 053. 2500 km: 65123:2000 054. 055. r1.dal.us - rewrite targets: 056. 1000 km: 65123:10033 057. 2500 km: 65123:840 058. 059. r1.sjo.us - rewrite targets: 060. 1000 km: 65123:10029 061. 2500 km: 65123:10033 65123:10029 062. 063. r1.nyc.us - rewrite targets: 064. 1000 km: 65123:10026 065. 2500 km: 65123:10026 65123:10033 066. 067. r1.tky.jp - rewrite targets: 068. 1000 km: 65123:30046 069. 2500 km: 65123:30046 070. 071. r1.sto.se - rewrite targets: 072. 1000 km: 65123:20022 073. 2500 km: 65123:2000 074. 075. r1.ams.nl - rewrite targets: 076. 1000 km: 65123:20020 65123:276 077. 2500 km: 65123:2000 078. Eleanor:~ job$ Now we can use the above to create the route-map for a customer connected to r1.sjo.us (San Jose, US): 079. ip prefix-list 15562:PREFIX seq 5 permit 194.33.96.0/24 080. ip prefix-list 15562:PREFIX:BLACKHOLE seq 5 permit 194.33.96.0/24 le 32 081. route-map IMPORT:FROM:15562:CUSTOMER:IPv4 permit 200 082. match ip address prefix-list 15562:PREFIX:BLACKHOLE 083. match community GLOBAL:BLACKHOLE 084. set community 5580:26220 no-export additive 085. set ip next-hop 10.0.0.1 086. set local-preference 1000000 087. route-map IMPORT:15562:CUSTOMER:IPv4 permit 300 088. match ip address prefix-list 15562:PREFIX:BLACKHOLE 089. match community SCOPED:ACTION 090. set community 5580:26220 no-export additive 091. set local-preference 650 092. continue 600 093. route-map IMPORT:15562:CUSTOMER:IPv4 permit 400 094. match ip address prefix-list 15562:PREFIX 095. set community 5580:26220 additive 096. set local-preference 650 097. route-map IMPORT:15562:CUSTOMER:IPv4 deny 500 098. route-map IMPORT:15562:CUSTOMER:IPv4 permit 600 099. match community OUTSIDE:1000KM:RADIUS:DISCARD 100. set community 65123:10029 additive 101. continue 1200 102. route-map IMPORT:15562:CUSTOMER:IPv4 permit 700 103. match community OUTSIDE:2500KM:RADIUS:DISCARD 104. set community 65123:10033 65123:10029 additive 105. continue 1200 106. route-map IMPORT:15562:CUSTOMER:IPv4 permit 900 107. match community OUTSIDE:THIS:COUNTRY:DISCARD 108. set community 65123:840 additive 109. continue 1200 110. route-map IMPORT:15562:CUSTOMER:IPv4 permit 1100 111. match community OUTSIDE:THIS:CONTINENT:DISCARD 112. set community 65123:1000 additive 113. route-map IMPORT:15562:CUSTOMER:IPv4 permit 1200 Various rewrites need to happen to offer the four scoped features we promised at the beginning of the document, the rewrites come either directly from the CMDB (line 108 and 112) or from the python program (line 100 and 104). Any network that wants to implement this should run software such as the python program every time a new POP is added, and update all IMPORT route-maps on all devices accordingly. Lines 081 to 113 bring us back to the second two examples where I illustrated what happens with various community strings if they are parsed through the RX:iBGP route-map. The customer in San Jose just sets 5580:662 (matched at line 102), but the IMPORT route-map will rewrite that to "5580:662 65123:10033 65123:10029" (line 104). Et voila, we have accomplished selective blackholing based on distance. :-) I ran some measurements with the RIPE Atlas system to test which probes can reach a given prefixes when a selective blackhole community is attached, the results are available here: http://noc.as5580.net/~job/selective_blackholing/ Disclaimer: Seeming route-map inefficiencies might be more related to the particular vendor on which I implemented this rather than my logic capabilities. If this document contains any errors, they most likely originated in the process of converting real world configuration to something of educational value. :-) I'd like to thank Saku Ytti Torsten Blum and Peter van Dijk for their gracious inspiration. If not for free and unhindered dialogue between organisations, we would never be able to create mechanisms like these. If you have any questions, please approach me through email or in person at NANOG60 in Atlanta! Kind regards, Job From mark.tinka at seacom.mu Mon Feb 10 20:33:49 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Feb 2014 22:33:49 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F388.6030301@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> Message-ID: <201402102233.49973.mark.tinka@seacom.mu> On Monday, February 10, 2014 05:43:04 PM Vlade Ristevski wrote: > We're still on the 12.4 train. I do use an ACL with less > than 100 entries which handle BCP38 and block a few bad > actors and private IPs on the Internet. I will be moving > the BCP38 ACL closer to the hosts before the upgrade so > the ACL will be a bit shorter in the future. Be sure to enable Turbo ACL's for best ACL processing optimization on this platform. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nick at foobar.org Mon Feb 10 20:33:43 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Feb 2014 20:33:43 +0000 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F92C11.40608@inblock.ru> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F91338.104@foobar.org> <52F92C11.40608@inblock.ru> Message-ID: <52F937A7.7090809@foobar.org> On 10/02/2014 19:44, Nikolay Shopik wrote: > You mean IOS XR? Which was never released for software based routers, > right? as it QNX in core. no, I meant modular IOS, not XR. This was an attempt to run a non bare-metal IOS. The kernel was based on qnx (http://goo.gl/9RSwHn), and cisco released it for the C6500 on the SXH and SXI code train. It turned out not to be much of a success in the end - very little of use was modularised, and it was canned after two minor code train releases. A bit sad really, because it never had enough time to mature. It was never released for any other platform. IOS-XE was a better implementation of non bare-metal ios Nick From mark.tinka at seacom.mu Mon Feb 10 20:35:50 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Feb 2014 22:35:50 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8F98A.3080405@n3network.ch> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F98A.3080405@n3network.ch> Message-ID: <201402102235.50708.mark.tinka@seacom.mu> On Monday, February 10, 2014 06:08:42 PM Nicolas Chabbey wrote: > I do remember we were able to forward around ~700Mbps of > 1500 bytes traffic with old IOS images and no ACLs. The trick is some of those additional features are better optimized in more modern IOS releases (SRE, 15S). Quagmire. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Feb 10 20:38:55 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Feb 2014 22:38:55 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F91338.104@foobar.org> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F91338.104@foobar.org> Message-ID: <201402102238.55590.mark.tinka@seacom.mu> On Monday, February 10, 2014 07:58:16 PM Nick Hilliard wrote: > in fact, the npe-g1 uses a BCM1250 which is a dual CPU > unit but vanilla IOS is not able to use the second CPU > for packet forwarding. Unsubstantiated rumour claimed > that modular IOS (QNX kernel) could push about 1.6x the > throughput of vanilla IOS, as it was smp capable. Pity > it was never released. Haha, you remind me of PXF (although that was the NSE-100 and NSE-150). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From joe at breathe-underwater.com Mon Feb 10 21:16:30 2014 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Mon, 10 Feb 2014 13:16:30 -0800 Subject: Looking for some guidance on creating route objects for ARIN In-Reply-To: <52F92BC6.5070607@west.net> References: <52F92BC6.5070607@west.net> Message-ID: <4837BC66-4F2E-436E-9DA2-D7F87B071CB1@breathe-underwater.com> Nevermind, someone already jumped in and helped me. Thanks though for the email. Joe Jenkins 909.636.2097 On Feb 10, 2014, at 11:43 AM, Jay Hennigan wrote: > On 2/10/14 9:08 AM, Joseph Jenkins wrote: >> I am trying to get the routing objects database. However I am getting back failures for the messages that I send in. I am wondering is it possible to get route objects created for the two /24s that I was given from my carriers allocations? If so what is the process to update the route objects database? I have my MNTNERID for my company, but when I use that to try and update the objects and attach them to my AS I am getting a failure. > > What are you sending (passwords redacted), to whom, and what failure > message are you receiving? > > -- > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From swmike at swm.pp.se Mon Feb 10 21:30:59 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 10 Feb 2014 22:30:59 +0100 (CET) Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8ED75.2090200@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> Message-ID: On Mon, 10 Feb 2014, Vlade Ristevski wrote: > Answers on and off list are appreciated. At 700-800 megabit/s aggregated througput (in+out), you're very clsoe to the max performance envelope of the G1. If you're going down this route, be prepared to purchase new hardware at short notice in case your traffic increases faster than you anticipated. -- Mikael Abrahamsson email: swmike at swm.pp.se From kemp at network-services.uoregon.edu Mon Feb 10 22:26:39 2014 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 10 Feb 2014 14:26:39 -0800 Subject: routeviews+BGPmon resources Message-ID: <52F9521F.9000306@network-services.uoregon.edu> The NANOG60 Talk: https://www.nanog.org/sites/default/files/monday.general.olschanowsky.routeviews.33.pdf BGPmon Homepage http://bgpmon.netsec.colostate.edu/ BGPmon Mailing List http://www.netsec.colostate.edu/mailman/listinfo/bgpmon BGPmon v7.3.3 Download http://bgpmon.netsec.colostate.edu/index.php/download BGPmon CPAN Modules e.g. http://www.cpan.org/authors/id/B/BG/BGPMON/ BGPmon-core BGPmon-Archiver BGPmon-AnalyticsDB BGPmon-CPM RouteViews BGPmon Dedicated Instances (rv2) livebgp-route-views2.routeviews.org (rv3) livebgp-route-views3.routeviews.org (rv6) livebgp-route-views6.routeviews.org (paix) livebgp-paix.routeviews.org (linx) livebgp-linx.routeviews.org RouteViews BGPmon Consolidating Instances (rv2+3+6) livebgp.routeviews.org (paix+linx) livebgpix.routeviews.org RouteViews MRT Archives {http,ftp}://archive.routeviews.org/ rsync ?list-only archive.routeviews.org::routeviews rsync ?av archive.routeviews.org::routeviews/bgpdata . If you plan on utilizing one of the BGPmon live feeds for an extended period, we would appreciate an e-mail. Please let us know your intended usage and the subnet you will be coming in from. For the RouteViews Instances, mail to help at routeviews.org. For general BGPmon questions, bgpmon at netsec.colostate.edu. The RouteViews Instances are considered a test platform. So while we do monitor, we are still debugging and doing updates. Feel free to ask if you have questions or comments. John Kemp RouteViews Network Engineer help at routeviews.org From mpetach at netflight.com Mon Feb 10 22:53:06 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Feb 2014 14:53:06 -0800 Subject: 2014.02.10 NANOG60 day 1 notes...ish Message-ID: I was going to put my notes from today's talk up at http://nanog.cluepon.net/index.php/Past_Events but discovered the site seems to have gone read-only, and my login doesn't work anymore. If people know what happened to the logins for that site, I'd be happy to add notes for today's talks to the page. Thanks! Matt From olivier.benghozi at wifirst.fr Mon Feb 10 23:53:08 2014 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Tue, 11 Feb 2014 00:53:08 +0100 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <201402102238.55590.mark.tinka@seacom.mu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F91338.104@foobar.org> <201402102238.55590.mark.tinka@seacom.mu> Message-ID: Cisco once implemented and released this feature to use the second core of the NPE-G1, most notably to manage the BRAS & en/decapsulations tasks for LAC/LNS/PTA (PPPoE, L2TP...), effectively offering such 1.6 factor. It was called MPF, and was released in special 12.3-YM IOS (in 2004/2005 I guess). The first core was still running "normal" IOS while the second core was running a dedicated microcode (acting as some sort of data plane). However several features were not available, and it was quite buggy and unstable (unless you only used the very minimum features implemented in the MPF microcode: no MSS adjust, no ACL for PPP sessions...). It was quickly deprecated anyway. http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_end-of-life_notice0900aecd8067dd9f.html Le 10 f?vr. 2014 ? 21:38, Mark Tinka a ?crit : > On Monday, February 10, 2014 07:58:16 PM Nick Hilliard > wrote: > >> in fact, the npe-g1 uses a BCM1250 which is a dual CPU >> unit but vanilla IOS is not able to use the second CPU >> for packet forwarding. Unsubstantiated rumour claimed >> that modular IOS (QNX kernel) could push about 1.6x the >> throughput of vanilla IOS, as it was smp capable. Pity >> it was never released. > > Haha, you remind me of PXF (although that was the NSE-100 > and NSE-150). > > Mark. From vristevs at ramapo.edu Tue Feb 11 02:05:16 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Mon, 10 Feb 2014 21:05:16 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F91A16.4080100@alvarezp.ods.org> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> Message-ID: <52F9855C.8000908@ramapo.edu> Are you suggesting getting the default gateway from both providers or getting the full table from one and using the default as a backup on the other (7206)? Thanks, On 2/10/2014 1:27 PM, Octavio Alvarez wrote: > On 02/10/2014 08:05 AM, Vlade Ristevski wrote: >> The ACL is a recent addition and we can probably do away with it. I >> didn't notice a significant increase in CPU or drops since adding it. >> But we usually peak at about 200Mbps on this link. The full routing >> table is a must since we're dual homed. > You don't necessarily need the full routing table for dual home, only > for outgoing load balance. You can have BGP, filter your routes away, > just leave a default gateway and still have dual homing. Your outgoing > traffic will work as if it were active-standby, though. > > My 0.02. -- Vlad From alvarezp at alvarezp.ods.org Tue Feb 11 02:52:12 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 10 Feb 2014 18:52:12 -0800 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F9855C.8000908@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> Message-ID: <52F9905C.2020505@alvarezp.ods.org> On 02/10/2014 06:05 PM, Vlade Ristevski wrote: > Are you suggesting getting the default gateway from both providers or > getting the full table from one and using the default as a backup on the > other (7206)? Whatever suits you best. Test and see. I'd just receive the full table anyway but filter them out, letting only the default routes go into the RIB. This should streamline your FIB. As I say, you lose outbound load balancing and your redundancy becomes all-or-nothing, but you save a few cycles. Again, I wouldn't recommend any of this because of the drawbacks, but along with other recommendations that others have made, like Turbo ACLs, it may buy you some time. From geraint at koding.com Tue Feb 11 07:10:23 2014 From: geraint at koding.com (Geraint Jones) Date: Tue, 11 Feb 2014 20:10:23 +1300 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F9905C.2020505@alvarezp.ods.org> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> Message-ID: Or assuming your using an Ethernet of some sort as your upstream connections you could grab something like a CCR from mikrotik for < $1k and sleep easy knowing you're only using 6% of it's capacity. Sent from my iPhone ? > On 11/02/2014, at 3:52 pm, Octavio Alvarez wrote: > >> On 02/10/2014 06:05 PM, Vlade Ristevski wrote: >> Are you suggesting getting the default gateway from both providers or >> getting the full table from one and using the default as a backup on the >> other (7206)? > > Whatever suits you best. Test and see. I'd just receive the full table > anyway but filter them out, letting only the default routes go into the > RIB. This should streamline your FIB. As I say, you lose outbound load > balancing and your redundancy becomes all-or-nothing, but you save a few > cycles. > > Again, I wouldn't recommend any of this because of the drawbacks, but > along with other recommendations that others have made, like Turbo ACLs, > it may buy you some time. > From pr at isprime.com Tue Feb 11 07:27:44 2014 From: pr at isprime.com (Phil Rosenthal) Date: Tue, 11 Feb 2014 02:27:44 -0500 Subject: NANOG Attendees: Flight cancellations on Wednesday Message-ID: Just a heads up to those attending NANOG in Atlanta. Delta has already cancelled 500 flights for wednesday, and will likely be canceling more. http://www.delta.com/content/www/en_US/traveling-with-us/alerts-and-advisories/Southeast-Winter-Weather.html You may want to check your reservations on your respective airlines, and reschedule flights and extend your hotel stay here, before everything is sold out. In my particular case, the flights for thursday to my home town were already almost entirely sold out. Regards, -Phil From vristevs at ramapo.edu Tue Feb 11 13:50:31 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 11 Feb 2014 08:50:31 -0500 Subject: carrier comparison In-Reply-To: <1071594870.664942.1391809368351.JavaMail.root@snappytelecom.net> References: <01c101cf234e$9b272990$d1757cb0$@webjogger.net> <52F3B2A8.8080405@ramapo.edu> <52F5489C.9090409@ramapo.edu> <1071594870.664942.1391809368351.JavaMail.root@snappytelecom.net> Message-ID: <52FA2AA7.7000607@ramapo.edu> I got the RFO today and what happened was: " The Cogent NOC investigated and found that one of our customers connected through a Verizon aggregated circuit to the router was being DDOS attacked. This type of attack can send excessive traffic to a customer?s interface either deliberately or accidentally, causing a spike in the router?s CPU usage. The Cogent NOC shut down the attacked customer?s connection to the network restoring normal router operations and our Customer Service Group worked with the customer to resolve the DDOS issue." On 2/7/2014 4:42 PM, Faisal Imtiaz wrote: > This is exactly what I thought had happened....The outage that affected you was one our two routers up-stream from your connection to that provider. > > I am not trying to defend any Carrier, but there is no 'routing protocol' what will react to this kind of an issue..... > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- >> From: "Vlade Ristevski" >> Cc: "nanog list" >> Sent: Friday, February 7, 2014 3:57:00 PM >> Subject: Re: carrier comparison >> >> We don't get a default route from them. At the time of the outage my bgp >> session was up and I had a full routing table from them. I didn't have >> much time to troubleshoot it in that state since we were down so I had >> to disable the session ASAP. Once the RFO comes in, I'll be asking a lot >> more questions about it. My only experience with BGP is as a customer so >> I'm not too familiar with the intricacies on the provider side. We had >> an outage in the AM the same day and we failed over just fine. I'm very >> curious why the same didn't happen in the evening. >> >> >> >> On 2/7/2014 3:03 PM, Bryan Socha wrote: >>> Did you verify your problem was announcements on the other side of the >>> outage? This sounds to me like you are using a bgp announced default >>> route from cogent which is always sent. I think the problem was you >>> were sending traffic out a path that was broken. Since you mentioned >>> your outbound balancing this would explain some packet loss and not >>> 100% loss. >>> >>> >>> Bryan Socha >>> Network Engineer >>> DigitalOcean >> -- >> Vlade Ristevski >> Network Manager >> IT Services >> Ramapo College >> (201)-684-6854 >> >> >> -- Vlad From jcurran at arin.net Tue Feb 11 14:31:13 2014 From: jcurran at arin.net (John Curran) Date: Tue, 11 Feb 2014 14:31:13 +0000 Subject: Taking Place NOW in Augusta Room - ARIN PPC Agenda for NANOG 60 Tuesday AM session Now Available References: Message-ID: <70B4B625-CC52-48E2-88B2-74D49ACCB93F@arin.net> All NANOG Attendees are welcome! /John Begin forwarded message: From: John Curran > Subject: ARIN PPC Agenda for NANOG 60 Tuesday AM session Now Available Date: February 10, 2014 at 9:48:48 AM EST To: NANOG list > NANOG 60 Attendees - Tomorrow morning there will be a Public Policy Consultation regarding a sizable number of potential changes to address policy at ARIN. Please find attached the list of policy proposals to be discussed; the session begins at 9:30 AM and all attendees are welcome! Text of each proposed changes is available at: https://www.arin.net/policy/proposals/ There is also a PPC Discussion Guide available with all of the draft policies, the ARIN policy development process, and the current policy manual available here: https://www.arin.net/ppcnanog60 Thank you, and look forward to seeing everyone tomorrow! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN PPC Agenda for NANOG 60 Now Available Date: February 4, 2014 at 2:08:08 PM EST To: arin-announce at arin.net Don't forget to mark your calendar and join us for ARIN's Public Policy Consultation (PPC), which will be held during NANOG 60 in Atlanta, Georgia on Tuesday, 11 February 2014, from 9:30 - 1:00 PM. The policy consultation is part of ARIN's Policy Development Process, and it is an open public discussion of Internet number resource policy. Registered NANOG 60 attendees do not need to register to participate in this session. ARIN welcomes members of the NANOG community who will not be in Atlanta to register as remote participants. If you plan to attend and are not registered for NANOG you must register for the ARIN PPC at the https://www.arin.net/ppcregister There is no registration fee for this half-day ARIN session, and it does not provide you entry to any other NANOG programming or social events. Current policy proposals up for discussion at this meeting are: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup Draft Policy ARIN-2014-1: Out of Region Use Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Draft Policy ARIN-2014-6: Remove 7.1 (Maintaining IN-ADDRs) Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update Proposals (193, 199 and 201) That first item is a Recommended Draft Policy; the ARIN Advisory Council recommends it as fair and technically sound policy. The Drafts and Proposals are works in progress. Text available at: https://www.arin.net/policy/proposals/ or in the PPC Discussion Guide: https://www.arin.net/ppcnanog60 ARIN will offer a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants can submit comments and questions to the discussions during the meeting. Register to attend in person or remotely today! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From anders at abundo.se Tue Feb 11 16:39:25 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Tue, 11 Feb 2014 17:39:25 +0100 Subject: SIP on FTTH systems In-Reply-To: References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> Message-ID: <52FA523D.3050208@abundo.se> On 2014-02-08 05:38, Mikael Abrahamsson wrote: >> Has there been any test if modern operating systems honor this? > > Well, they would be defective if they didn't. Also, you don't even need to > announce the prefix at all, even with L-bit cleared. You can make RAs with M > and O bit set that won't contain any prefix at all. Been there, done that. Pretty clever. Not sure why I missed this it is fairly clear in the RFCs. Is there not an issue with this if the customer is connected directly to the access device over L2? They will not communicate with each other direcly, all traffic will be exchanged through the default gateway? (same as has been seen with proxy-arp in such networks) > At least linux worked perfectly. I think I need to do some experiments here... /Anders From braymo at llnw.com Tue Feb 11 17:02:32 2014 From: braymo at llnw.com (Bradley Raymo) Date: Tue, 11 Feb 2014 12:02:32 -0500 Subject: NANOG Attendees: Flight cancellations on Wednesday In-Reply-To: References: Message-ID: USAIR has Canceled flights on Thursday now as well. http://www.usairways.com/TravelCenter/Advisories.aspx [image: Limelight Networks] Bradley Raymo - Senior Network Planner *p:* +1 602 850 5716 | *m: *+1 623 703 5300 [image: Show It. Tell It. Every. Way. Every. Where.] www.limelight.com [image: Facebook] [image: LinkedIn] [image: Twitter] On Tue, Feb 11, 2014 at 2:27 AM, Phil Rosenthal wrote: > Just a heads up to those attending NANOG in Atlanta. > > Delta has already cancelled 500 flights for wednesday, and will likely be > canceling more. > > > http://www.delta.com/content/www/en_US/traveling-with-us/alerts-and-advisories/Southeast-Winter-Weather.html > > You may want to check your reservations on your respective airlines, and > reschedule flights and extend your hotel stay here, before everything is > sold out. > > In my particular case, the flights for thursday to my home town were > already almost entirely sold out. > > Regards, > -Phil > From kamtha at ak-labs.net Tue Feb 11 20:01:44 2014 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Tue, 11 Feb 2014 15:01:44 -0500 Subject: Reliable Dedicated/VPS providers in Canada? Message-ID: <20140211200144.GA35388@ak-labs.net> Hi, I was wondering if anyone could share some experiences with providers in the great white north. We have a few providers now and not happy with them. Cheap flimsly virtual servers that charge .50cents a gig for BW overages.. :/ Any feedback would be appreciated.. Cheers, Carlos. From alter3d at alter3d.ca Tue Feb 11 20:32:10 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 11 Feb 2014 12:32:10 -0800 Subject: Reliable Dedicated/VPS providers in Canada? Message-ID: <20140211123210.A87DE14@m0048140.ppops.net> I've been quite happy with the servers I'm renting from OVH (http://www.ovh.com/ca/en/) in their new Montreal data center, which is their entry into the North American market; they've operated in Europe for quite a long time. - Pete --- kamtha at ak-labs.net wrote: From: Carlos Kamtha To: nanog at nanog.org Subject: Reliable Dedicated/VPS providers in Canada? Date: Tue, 11 Feb 2014 15:01:44 -0500 Hi, I was wondering if anyone could share some experiences with providers in the great white north. We have a few providers now and not happy with them. Cheap flimsly virtual servers that charge .50cents a gig for BW overages.. :/ Any feedback would be appreciated.. Cheers, Carlos. From mark at metricnetservices.com Tue Feb 11 21:03:34 2014 From: mark at metricnetservices.com (Mark Walters) Date: Tue, 11 Feb 2014 13:03:34 -0800 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> Message-ID: We run 7206 NPE-G1s on some GigE peering points. At about 800Mbps of aggregate Internet traffic (inbound + outbound, as measured from Cacti) the CPU sits around 70%. Setup: - inbound and outbound Internet-facing ACLs (50 lines and 25 lines respectively, turbo ACL) - Inbound Internet-facing policy-map to remark DSCP (references 7-line ACL) - minimal routes via BGP (approx 1500) - 15.1 SP train YMMV, but they work well for us in this scenario. With downstream-to-upstream traffic patterns of approx 7-to-1 the GigE and CPU will peak out at about the same time. Side note - our G2s at that same 800Mbps traffic rate run at approx 60% CPU. Cheers Mark W On 2/11/14 2:10 AM, "Geraint Jones" wrote: >Or assuming your using an Ethernet of some sort as your upstream >connections you could grab something like a CCR from mikrotik for < $1k >and sleep easy knowing you're only using 6% of it's capacity. > >Sent from my iPhone ? > >> On 11/02/2014, at 3:52 pm, Octavio Alvarez >>wrote: >> >>> On 02/10/2014 06:05 PM, Vlade Ristevski wrote: >>> Are you suggesting getting the default gateway from both providers or >>> getting the full table from one and using the default as a backup on >>>the >>> other (7206)? >> >> Whatever suits you best. Test and see. I'd just receive the full table >> anyway but filter them out, letting only the default routes go into the >> RIB. This should streamline your FIB. As I say, you lose outbound load >> balancing and your redundancy becomes all-or-nothing, but you save a few >> cycles. >> >> Again, I wouldn't recommend any of this because of the drawbacks, but >> along with other recommendations that others have made, like Turbo ACLs, >> it may buy you some time. >> > From landonstewart at gmail.com Tue Feb 11 21:14:38 2014 From: landonstewart at gmail.com (Landon) Date: Tue, 11 Feb 2014 13:14:38 -0800 Subject: Reliable Dedicated/VPS providers in Canada? In-Reply-To: <20140211200144.GA35388@ak-labs.net> References: <20140211200144.GA35388@ak-labs.net> Message-ID: On 11 February 2014 12:01, Carlos Kamtha wrote: > Hi, > > I was wondering if anyone could share some experiences with providers > in the great white north. > > We have a few providers now and not happy with them. Cheap flimsly > virtual servers that charge .50cents a gig for BW overages.. :/ > > Any feedback would be appreciated.. > Full disclosure - I'm biased because I work there but check out http://iweb.com/cloud/. -- Landon Stewart From acv at miniguru.ca Tue Feb 11 21:33:02 2014 From: acv at miniguru.ca (Alexandre Carmel-Veilleux) Date: Tue, 11 Feb 2014 16:33:02 -0500 Subject: Reliable Dedicated/VPS providers in Canada? In-Reply-To: <20140211123210.A87DE14@m0048140.ppops.net> References: <20140211123210.A87DE14@m0048140.ppops.net> Message-ID: OVH is a bit more then a VPS, they lease dedicated servers with vSphere or vCloud. iWeb is an actual VPS provider, never tried their VPS but had decent experience with a dedicated server from them for the usual vanity email purpose you'd use a VPS for now. iWeb B/W is 0.10$/GB and instance run time starts at 0.06$/hour. Alex On Tue, Feb 11, 2014 at 3:32 PM, Peter Kristolaitis wrote: > I've been quite happy with the servers I'm renting from OVH ( > http://www.ovh.com/ca/en/) in their new Montreal data center, which is > their entry into the North American market; they've operated in Europe for > quite a long time. > > - Pete > From shopik at inblock.ru Tue Feb 11 21:37:00 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Wed, 12 Feb 2014 01:37:00 +0400 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> Message-ID: <52FA97FC.2090909@inblock.ru> Our G2 with BGP full-view and sampled netflow 1:100 doing 1,2Gbit with about 88% load. On 12.02.2014 1:03, Mark Walters wrote: > Side note - our G2s at that same 800Mbps traffic rate run at approx 60% > CPU. From paul at nashnetworks.ca Tue Feb 11 21:38:20 2014 From: paul at nashnetworks.ca (Paul Nash) Date: Tue, 11 Feb 2014 16:38:20 -0500 Subject: Reliable Dedicated/VPS providers in Canada? In-Reply-To: <20140211200144.GA35388@ak-labs.net> References: <20140211200144.GA35388@ak-labs.net> Message-ID: Depends what you?re looking for, what you want to pay. I host dedicated machines for a bunch of clients, who get a realio-trulio machine (something like a DL360) with unlimited transfer and the OS of their choice. If they want it, they even get maintenance and after-hours on-call tech staff who actually know what they are doing. But it costs them more than the cheap $15/month we?ll-hosy-your-wesite packages, typically well north of $100/month for a fast machine with maintenance, somewhat less for an older, slower box unmaintained. All housed at 151 Front, THE premier Canadian data centre. Drop me a line if you are interested, and we can talk. I have also been burned by the ?cheap? (usually quality, not price) VPS instances on oversold hardware in someone?s basement. paul On Feb 11, 2014, at 3:01 PM, Carlos Kamtha wrote: > Hi, > > I was wondering if anyone could share some experiences with providers > in the great white north. > > We have a few providers now and not happy with them. Cheap flimsly > virtual servers that charge .50cents a gig for BW overages.. :/ > > Any feedback would be appreciated.. > > Cheers, > Carlos. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1974 bytes Desc: not available URL: From swmike at swm.pp.se Tue Feb 11 22:41:42 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Feb 2014 23:41:42 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <52FA523D.3050208@abundo.se> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> <52FA523D.3050208@abundo.se> Message-ID: On Tue, 11 Feb 2014, Anders L?winger wrote: > Is there not an issue with this if the customer is connected directly to > the access device over L2? They will not communicate with each other > direcly, all traffic will be exchanged through the default gateway? Yes, what's the problem with that? > (same as has been seen with proxy-arp in such networks) Local-proxy-arp, yes. > I think I need to do some experiments here... I'd venture to say that any IPv6 implementation that doesn't support this is broken and should be fixed by the implementor. -- Mikael Abrahamsson email: swmike at swm.pp.se From cgrundemann at gmail.com Tue Feb 11 23:10:06 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 11 Feb 2014 16:10:06 -0700 Subject: Operators and the IETF Message-ID: Hey all, As promised in my lightning talk just now, here is the Operators and the IETF info: Details: http://www.internetsociety.org/deploy360/blog/2014/01/new-project-operators-and-the-ietf/ Survey: https://internetsociety2.wufoo.com/forms/operators-and-the-ietf/ Please consider taking the survey, and sharing it with others. Thanks! ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From blake at ispn.net Tue Feb 11 23:26:24 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 11 Feb 2014 17:26:24 -0600 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52F8ED75.2090200@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> Message-ID: <52FAB1A0.7040008@ispn.net> I generally spec the NPE-G1 as "up to 1Gbps" if you're using the onboard ports. This assumes ISP type loads with little upstream, lots of downstream, and relatively large flows (mostly 1500 byte packets) on ethernet. It sounds like this fits your usage case well. If one were to throw in ATM or another media type I'd drop the performance quote to half. If you cannot make use of CEF, or use source based routing, drop the performance to ~ 100Mbps. NPE-G1 with 1Gbps of RAM can take 2 full BGP feeds (about 700MB of memory used). Each additional feed will likely require another 100-200MB of memory (no soft reconfig). NPE-G2 w/ 2GB of RAM can take several full feeds and may be able to operate up to 2Gbps using the onboard ports. I haven't pushed one of these to its limits, most people seem to move on to newer platforms first. --Blake Vlade Ristevski wrote the following on 2/10/2014 9:17 AM: > We are looking to double the bandwidth on one of our circuits from > 300Mbps to 600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 > card. These seem like very popular routers so I'm hoping a few people > on this list have them deployed. If you or a customer have these > deployed, how much bandwidth have you seen them handle? This will be > handling dorm traffic at a college so it's mostly download. The 7206 > handles our 300 Mbps circuit just fine, but we are moving it to our > 600Mbps circuit. At peak we've seen the following numbers for that > circuit: > > > 30 second input rate 559982000 bits/sec, 55809 packets/sec > 30 second output rate 55429000 bits/sec, 32598 packets/sec > 267756984712 packets input, 333325152556755 bytes, 0 no buffer > > This is the interface that connects to our provider. As you can see > its almost all download traffic. Our ASR1002 handles it without a > sweat but I'm a little skeptical of whether the 7206 will hold up. > > Answers on and off list are appreciated. > > Thanks, > > From anders at abundo.se Wed Feb 12 00:32:43 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Wed, 12 Feb 2014 01:32:43 +0100 Subject: SIP on FTTH systems In-Reply-To: References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> <52FA523D.3050208@abundo.se> Message-ID: <52FAC12B.8080102@abundo.se> On 2014-02-11 23:41, Mikael Abrahamsson wrote: >> Is there not an issue with this if the customer is connected directly to the >> access device over L2? They will not communicate with each other direcly, >> all traffic will be exchanged through the default gateway? > > Yes, what's the problem with that? Bad description by me. I'll try again. If I have two PCs in my home, connected with GE to a L2 switch and I buy 10 Mbit Internet access, I don't want traffic between my two PCs to be exchanged through the default route. They could possible communicate directly using link-local, but I'm not sure how they would find each other? Default gw could send a redirect... > I'd venture to say that any IPv6 implementation that doesn't support this is > broken and should be fixed by the implementor. Agree. /Anders From frnkblk at iname.com Wed Feb 12 04:47:35 2014 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 11 Feb 2014 22:47:35 -0600 Subject: SIP on FTTH systems In-Reply-To: <52FAC12B.8080102@abundo.se> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> <52FA523D.3050208@abundo.se> <52FAC12B.8080102@abundo.se> Message-ID: <015201cf27ad$8c889320$a599b960$@iname.com> In the scenario you're describing does each PC get its own /64 (or /56 or /48) directly from the service provider? Or are they in the same netblock? Frank -----Original Message----- From: Anders L?winger [mailto:anders at abundo.se] Sent: Tuesday, February 11, 2014 6:33 PM To: Mikael Abrahamsson Cc: nanog at nanog.org Subject: Re: SIP on FTTH systems On 2014-02-11 23:41, Mikael Abrahamsson wrote: >> Is there not an issue with this if the customer is connected directly to the >> access device over L2? They will not communicate with each other direcly, >> all traffic will be exchanged through the default gateway? > > Yes, what's the problem with that? Bad description by me. I'll try again. If I have two PCs in my home, connected with GE to a L2 switch and I buy 10 Mbit Internet access, I don't want traffic between my two PCs to be exchanged through the default route. They could possible communicate directly using link-local, but I'm not sure how they would find each other? Default gw could send a redirect... > I'd venture to say that any IPv6 implementation that doesn't support this is > broken and should be fixed by the implementor. Agree. /Anders From swmike at swm.pp.se Wed Feb 12 06:29:21 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 12 Feb 2014 07:29:21 +0100 (CET) Subject: SIP on FTTH systems In-Reply-To: <015201cf27ad$8c889320$a599b960$@iname.com> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> <52FA523D.3050208@abundo.se> <52FAC12B.8080102@abundo.se> <015201cf27ad$8c889320$a599b960$@iname.com> Message-ID: On Tue, 11 Feb 2014, Frank Bulk wrote: > In the scenario you're describing does each PC get its own /64 (or /56 > or /48) directly from the service provider? Or are they in the same > netblock? They would each get their own /128 via DHCPv6 IA_NA, and they would end up having this /128 and a default route, nothing else, so all traffic between them on their GUA addresses would go over the ISP connection. Only way to solve this is for the customer to buy a router that uses IA_PD, put the PCs behind it, and then they would be able to communicate directly with each other. -- Mikael Abrahamsson email: swmike at swm.pp.se From koalafil at gmail.com Wed Feb 12 12:20:27 2014 From: koalafil at gmail.com (Filiz Yilmaz) Date: Wed, 12 Feb 2014 13:20:27 +0100 Subject: Fwd: Call for Presentations RIPE 68 References: <266D14B7-7D9B-433E-9805-D53CCE92D756@gmail.com> Message-ID: <1FEF8C2A-48ED-4F19-A8F7-0527F65C38D5@gmail.com> Colleagues, Please note the approaching deadline of 2 March 2014 for RIPE 68 Plenary agenda. This is a gentle reminder that PC is awaiting for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. NANOG, have a good last day in Atlanta! Kind regards Filiz Yilmaz RIPE PC Chair http://www.ripe.net/ripe/meetings/ripe-meetings/pc Begin forwarded message: > From: Filiz Yilmaz > Subject: Call for Presentations RIPE 68 > Date: 19 Nov 2013 19:04:34 GMT+01:00 > To: ripe-list at ripe.net, "nanog at nanog.org" > Cc: "pc at ripe.net Committee" > > > Dear colleagues, > > Please find the CFP for RIPE 68 below or at https://ripe68.ripe.net/submit-topic/cfp/. > > The deadline for submissions is 2 March 2014. > Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. > > Kind regards > > Filiz Yilmaz > RIPE PC Chair > http://www.ripe.net/ripe/meetings/ripe-meetings/pc > > > --------------------- > > Call for Presentations > > A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. > > RIPE 68 will take place from 12 ? 16 May 2014 in Warsaw, Poland. > > The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 68. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: > > ? IPv6 deployment > ? Managing IPv4 scarcity in operations > ? Commercial transactions of IPv4 addresses > ? Data centre technologies > ? Network and DNS operations > ? Internet governance and regulatory practices > ? Network and routing security > ? Content delivery > ? Internet peering and mobile data exchange > > Submissions > > RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. > > The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at > https://ripe68.ripe.net/submit-topic/presentation-formats/ > > Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. > > In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for ?lightning talks?, which are selected immediately before or during the conference. > > The following general requirements apply: > > - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 2 March 2014, using the meeting submission system at https://ripe68.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. > > - Lightning talks should also be submitted using the meeting submission system (https://ripe68.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice ? in some cases on the same day but often one day prior to the relevant session. > > - Presenters should indicate how much time they will require. > See more information on time slot allocations per presentation format at https://ripe68.ripe.net/submit-topic/presentation-formats/ > > - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. > > - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. > > If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. > > --------------------- > > From thomas.mangin at exa-networks.co.uk Wed Feb 12 16:57:13 2014 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Wed, 12 Feb 2014 16:57:13 +0000 Subject: DNS/NTP , a solution ! Message-ID: Hello, Because : - Exa has been under attack way too much these last weeks - We hate to have to deal with it Because: - Andrisoft seems cool but does not do FlowSpec - Arbor is known for its price (and features) - I am from Yorkshire (How much do you pay me to find bugs in your shinny application ?) Because: - We can ... - And people can not be bothered to fix the problem at source ! I have been working on making our internal tool ( Thank you Daniel ) something which can be built on and released to the community. The repository is here: https://github.com/Exa-Networks/exaddos The code is not even one week old but it can : - use SNMP to monitor your EBGP interfaces - parse IPFIX to find your top speakers - provide you the data in an HORRIBLE web page ( but all the rendering is client side, so feel free to fix that !) Now I would love some help ... I am NOT a web designer who find Javascript easy (I can handle jquery and basic stuff but nice CSS is not my cup of tea), so it will not look nice unless someone else make it so. I can provide the underlying data via JSON in whatever way one may need to allow : - graphing of links - allow to drill down on top speakers to find proto / ports information - "one click" get rid of that DDOS for I did some of this stuff with ExaProxy so I am not totally useless but god knows it is not my strength ! So any help would be welcome, so I can go back on coding on BGP and not DDOS. Thomas PS: I created a G+ community ExaDDOS .. I will try to add a mailing list later on. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mpetach at netflight.com Wed Feb 12 19:20:16 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 12 Feb 2014 11:20:16 -0800 Subject: NANOG60 notes Message-ID: I've been pinged by a few people who had to travel midway through NANOG due to weather if I would be posting notes up; yes, though it looks like cluepon.net isn't writeable, so for now I'm putting them up on my home box, but when cluepon.net is writeable again, I'll copy them over there. For now: http://kestrel3.netflight.com/2014.02.10-NANOG60-day1-morning.txt http://kestrel3.netflight.com/2014.02.10-NANOG60-day1-afternoon.txt http://kestrel3.netflight.com/2014.02.11-NANOG60-day2-morning.txt http://kestrel3.netflight.com/2014.02.11-NANOG60-day2-afternoon.txt http://kestrel3.netflight.com/2014.02.12-NANOG60-day3-morning.txt Sorry about the weather! Matt From me at anuragbhatia.com Wed Feb 12 20:54:24 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 13 Feb 2014 02:24:24 +0530 Subject: Blocking of domain strings in iptables In-Reply-To: <52F66D9D.1000205@tiggee.com> References: <52F66D9D.1000205@tiggee.com> Message-ID: Thanks everyone for useful responses. I almost used script mentioned by Stephane (http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py) but I realized that for a rule for "domain.com" it blocks "domain.com" only and their was no easy way out to block subdomains as well. In last few days after my post, I noticed traffic in pattern of sub1.sub2.domain.com where sub1 and sub2 are randomly generated strings. I tried creating .domain.com and other rules in u32 but didn't help for subdomain. Also since there were very high number of subdomains (but limited domains), possibility to generate u32 rule for each sub didn't made sense. I re-visited Hexadecimal string with 03 and 00 for dot was actually able to help. RPZ and some other option I am still exploring. Thanks. On Sat, Feb 8, 2014 at 11:17 PM, David Miller wrote: > On 02/08/2014 09:40 AM, William Herrin wrote: > > On Sat, Feb 8, 2014 at 3:34 AM, Jonathan Lassoff wrote: > >> This is going to be tricky to do, as DNS packets don't necessarily > contain > >> entire query values or FQDNs as complete strings due to packet label > >> compression (remember, original DNS only has 512 bytes to work with). > > > > Howdy, > > > > The DNS query essentially always contains the full string in a > > sequence. It doesn't *have* to per the protocol but you'll be hard > > pressed to find a real-world example where it doesn't. > > > > The catch is, the dots aren't encoded. The components of the name > > being queried are separated by a byte indicating the length of the > > next piece. So, instead of www.google.com the query packet contains > > www 0x06 google 0x03 com. > > For the completeness of the archives, the length of the first token is > also encoded and final terminator is 0. > > 0x03 www 0x06 google 0x03 com 0x00 > > > -DMM > > > > > You can implement this with --hex-string instead of --string but > > you'll have to convert the entire thing to hex first > > > > Regards, > > Bill Herrin > > > > > > > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From vristevs at ramapo.edu Wed Feb 12 22:28:47 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Wed, 12 Feb 2014 17:28:47 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52FA97FC.2090909@inblock.ru> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> <52FA97FC.2090909@inblock.ru> Message-ID: <52FBF59F.6070801@ramapo.edu> Thanks for all the responses. It's been very helpful. Based on your collective feedback, I'm definitely going to retire the 7206 this summer. I'm looking at the ASR-1002-X and Juniper MX-5, MX-10. I may as well go with something 10Gig capable. My Cisco SE brought up an interesting alternative. This summer we're replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. It is where all our internal Fiber terminates and where internal routing happens. He said we can add extra memory and terminate our BGP sessions here and use that for our Internet connections. After thinking it over, I'd still rather have dedicated routers for our Internet access but I'm curious what you guys think about this suggestion. -- Vlad From dbrisson at uvm.edu Thu Feb 13 03:06:03 2014 From: dbrisson at uvm.edu (Dan Brisson) Date: Wed, 12 Feb 2014 22:06:03 -0500 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52FBF59F.6070801@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> <52FA97FC.2090909@inblock.ru> <52FBF59F.6070801@ramapo.edu> Message-ID: <52FC369B.7060804@uvm.edu> > > My Cisco SE brought up an interesting alternative. This summer we're > replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. > It is where all our internal Fiber terminates and where internal > routing happens. He said we can add extra memory and terminate our > BGP sessions here and use that for our Internet connections. After > thinking it over, I'd still rather have dedicated routers for our > Internet access but I'm curious what you guys think about this > suggestion. I think at the Internet edge, physical separation trumps logical unless you have no other choice. Personally, I would keep them separate. My .02, -dan From swmike at swm.pp.se Thu Feb 13 03:08:02 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 13 Feb 2014 04:08:02 +0100 (CET) Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52FBF59F.6070801@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> <52FA97FC.2090909@inblock.ru> <52FBF59F.6070801@ramapo.edu> Message-ID: On Wed, 12 Feb 2014, Vlade Ristevski wrote: > My Cisco SE brought up an interesting alternative. This summer we're > replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. It > is where all our internal Fiber terminates and where internal routing > happens. He said we can add extra memory and terminate our BGP sessions > here and use that for our Internet connections. After thinking it over, > I'd still rather have dedicated routers for our Internet access but I'm > curious what you guys think about this suggestion. A lot of people use SUP720-3BXL and RSP720-3CXL for full BGP table routing. This will work just fine until the IPv4 routing table reaches 800k entries or something (if you want to do IPv6 at the same time, you probably don't want to go over 800k IPv4 routes and 50k IPv6 routes to have a little bit of margin of the around 1M routes the XL sup can handle). -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Thu Feb 13 08:41:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 13 Feb 2014 10:41:10 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52FBF59F.6070801@ramapo.edu> References: <52F8ED75.2090200@ramapo.edu> <52FA97FC.2090909@inblock.ru> <52FBF59F.6070801@ramapo.edu> Message-ID: <201402131041.11157.mark.tinka@seacom.mu> On Thursday, February 13, 2014 12:28:47 AM Vlade Ristevski wrote: > My Cisco SE brought up an interesting alternative. This > summer we're replacing our 6513 Sup720 with a pair of > 6807 with redundant Sup 2Ts. It is where all our > internal Fiber terminates and where internal routing > happens. He said we can add extra memory and terminate > our BGP sessions here and use that for our Internet > connections. After thinking it over, I'd still rather > have dedicated routers for our Internet access but I'm > curious what you guys think about this suggestion. If you have the budget, run dedicated peering/upstream routers. Hierarchical separation of functions at the hardware level provides lots of flexibility in other areas as your network grows. If cash is not a constraint, go for it, I'd say. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From anders at abundo.se Thu Feb 13 09:37:54 2014 From: anders at abundo.se (=?ISO-8859-1?Q?Anders_L=F6winger?=) Date: Thu, 13 Feb 2014 10:37:54 +0100 Subject: SIP on FTTH systems In-Reply-To: <015201cf27ad$8c889320$a599b960$@iname.com> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <52F5AB22.4050500@abundo.se> <52FA523D.3050208@abundo.se> <52FAC12B.8080102@abundo.se> <015201cf27ad$8c889320$a599b960$@iname.com> Message-ID: <52FC9272.2010006@abundo.se> On 2014-02-12 05:47, Frank Bulk wrote: > In the scenario you're describing does each PC get its own /64 (or /56 or > /48) directly from the service provider? Or are they in the same netblock? They are connected through a L2 switch directly to the access port. Mikael responded in another email, and verified that traffic will be exchanged trough the default gateway even if the PCs are in the same home. If CPE is L3 capable it's not an issue. /Anders From mark.tinka at seacom.mu Thu Feb 13 10:38:32 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 13 Feb 2014 12:38:32 +0200 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: References: <52F8ED75.2090200@ramapo.edu> <52FBF59F.6070801@ramapo.edu> Message-ID: <201402131238.33178.mark.tinka@seacom.mu> On Thursday, February 13, 2014 05:08:02 AM Mikael Abrahamsson wrote: > A lot of people use SUP720-3BXL and RSP720-3CXL for full > BGP table routing. This will work just fine until the > IPv4 routing table reaches 800k entries or something (if > you want to do IPv6 at the same time, you probably don't > want to go over 800k IPv4 routes and 50k IPv6 routes to > have a little bit of margin of the around 1M routes the > XL sup can handle). Or route churn which quickly shows the inadequacies of the CPU in those control planes. An NPE-G1/G2 has a much quicker CPU. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Feb 13 10:41:13 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 13 Feb 2014 12:41:13 +0200 Subject: SIP on FTTH systems In-Reply-To: <52FC9272.2010006@abundo.se> References: <25146960.7480.1391752764897.JavaMail.root@benjamin.baylink.com> <015201cf27ad$8c889320$a599b960$@iname.com> <52FC9272.2010006@abundo.se> Message-ID: <201402131241.13588.mark.tinka@seacom.mu> On Thursday, February 13, 2014 11:37:54 AM Anders L?winger wrote: > They are connected through a L2 switch directly to the > access port. > > Mikael responded in another email, and verified that > traffic will be exchanged trough the default gateway > even if the PCs are in the same home. > > If CPE is L3 capable it's not an issue. Ideally, CPE would be Layer 3-capable. I can see situations where providers offer you only one port off their AN into your home. I can also see this further enhanced with permiting only one MAC address on that port. In such a case, a IP-capable CPE device is ideal. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From cb.list6 at gmail.com Thu Feb 13 17:06:17 2014 From: cb.list6 at gmail.com (Cb B) Date: Thu, 13 Feb 2014 09:06:17 -0800 Subject: ddos attack blog Message-ID: Good write up, includes name and shame for AT&T Wireless, IIJ, OVH, DTAG and others http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack Standard plug for http://openntpproject.org/ and http://openresolverproject.org/ and bcp38 , please fix/help. For those of you paying attention to the outage list, this is a pretty big deal that has had daily ramification for some very big networks https://puck.nether.net/pipermail/outages/2014-February/date.html In general, i think UDP is doomed to be blocked and rate limited -- tragedy of the commons. But, it would be nice if folks would just fix the root of the issue so the rest of us don't have go there... Regards, CB From jared at puck.nether.net Thu Feb 13 17:17:10 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 13 Feb 2014 12:17:10 -0500 Subject: ddos attack blog In-Reply-To: References: Message-ID: <286F9E1D-C426-46A3-BD14-D5A4874C87E4@puck.nether.net> On Feb 13, 2014, at 12:06 PM, Cb B wrote: > Good write up, includes name and shame for AT&T Wireless, IIJ, OVH, > DTAG and others > > http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack > > Standard plug for http://openntpproject.org/ and > http://openresolverproject.org/ and bcp38 , please fix/help. > > For those of you paying attention to the outage list, this is a pretty > big deal that has had daily ramification for some very big networks > https://puck.nether.net/pipermail/outages/2014-February/date.html > > In general, i think UDP is doomed to be blocked and rate limited -- > tragedy of the commons. But, it would be nice if folks would just fix > the root of the issue so the rest of us don't have go there... While I'm behind some of the inventory projects (so you can go ahead and fix.. let me know if you need/want the URLs to see data for your networks)... I must provide credit to those behind the "Amplification Hell" talk at NDSS. If you are at all interested in what is going on, you should attend or review the content. http://www.internetsociety.org/ndss2014/programme BCP-38 on your customers is going to be critical to prevent the abuse reaching your network. Please ask your vendors for it, and ask for your providers to filter your network to prevent you originating this abuse. If you operate hosted VMs, servers, etc.. please make sure those netblocks are secured as well. You can easily check your network (As can the bad guys!) here: http://spoofer.cmand.org/ - Jared From fergdawgster at mykolab.com Thu Feb 13 17:30:06 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 13 Feb 2014 09:30:06 -0800 Subject: ddos attack blog In-Reply-To: References: Message-ID: <52FD011E.8080909@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/13/2014 9:06 AM, Cb B wrote: > Good write up, includes name and shame for AT&T Wireless, IIJ, > OVH, DTAG and others > > http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack > > Standard plug for http://openntpproject.org/ and > http://openresolverproject.org/ and bcp38 , please fix/help. > > For those of you paying attention to the outage list, this is a > pretty big deal that has had daily ramification for some very big > networks > https://puck.nether.net/pipermail/outages/2014-February/date.html > > In general, i think UDP is doomed to be blocked and rate limited > -- tragedy of the commons. But, it would be nice if folks would > just fix the root of the issue so the rest of us don't have go > there... > The alternative is get people to understand that anti-spoofing is good, and efforts to combat spoofing should be encouraged. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL9AR4ACgkQKJasdVTchbJZYwEAivI00Yq7RSMze74GFQKEyCeH pS2s8TH0ba08NWKC22AA/jyN35xonJBzldJA8/xlzhnuLnyOFB0Y7GKZ8NiqRiRl =ItxR -----END PGP SIGNATURE----- From blake at ispn.net Thu Feb 13 19:56:14 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 13 Feb 2014 13:56:14 -0600 Subject: 7206 VXR NPE-G1 throughput In-Reply-To: <52FC369B.7060804@uvm.edu> References: <52F8ED75.2090200@ramapo.edu> <52F8F0AA.4060302@signet.nl> <52F8F388.6030301@ramapo.edu> <52F8F676.4@signet.nl> <52F8F8CD.6090808@ramapo.edu> <52F91A16.4080100@alvarezp.ods.org> <52F9855C.8000908@ramapo.edu> <52F9905C.2020505@alvarezp.ods.org> <52FA97FC.2090909@inblock.ru> <52FBF59F.6070801@ramapo.edu> <52FC369B.7060804@uvm.edu> Message-ID: <52FD235E.6000803@ispn.net> Dan Brisson wrote the following on 2/12/2014 9:06 PM: > >> >> My Cisco SE brought up an interesting alternative. This summer we're >> replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. >> It is where all our internal Fiber terminates and where internal >> routing happens. He said we can add extra memory and terminate our >> BGP sessions here and use that for our Internet connections. After >> thinking it over, I'd still rather have dedicated routers for our >> Internet access but I'm curious what you guys think about this >> suggestion. > I think at the Internet edge, physical separation trumps logical > unless you have no other choice. Personally, I would keep them separate. > > My .02, > > -dan > A point to consider: Layer 3 infrastructure and the services that run on L3 devices (ssh, ntp, routing protocols, packet classification, monitoring, shaping, etc) have a much higher surface area for attack and bugs. They therefore (theoretically) require more frequent updates and encounter more problems. Do you want to disrupt your layer 2 infrastructure every time you update your L3 infrastructure? Do you want to expose your L2 infrastructure to the potential bugs in L3 and above code? Separate physical devices can create a more available network. Counter point: A router in front of a router adds an additional point of failure. If you're not gaining anything (features, redundancy, etc) by its introduction you're just wasting money and hurting your (potential) availability. If you provide a lot of L2 only services, or have a substantial amount of traffic that never leaves L2, I would recommend dividing your network by OSI layer. This allows you to easily have different update, security, warranty, etc policies for the different services your network provides. If you are an ISP offering L3 only services or all traffic on your network hits L3, then a failure of any one layer will disrupt all communication; In this case, you may save time/money and increase availability by combining L2 and L3+ functions. --Blake From tdurack at gmail.com Thu Feb 13 20:20:05 2014 From: tdurack at gmail.com (Tim Durack) Date: Thu, 13 Feb 2014 15:20:05 -0500 Subject: Tail-F NCS? (Or similar network configuration management.) Message-ID: Looking for real-world experience with Tail-f NCS (or similar network configuration management.) Not looking for rancid, we have a homebrew config collection that works well. Looking for something significantly better than I can write myself. Not looking for sales either, I have people for that :-) On/off list is fine. -- Tim:> From jhaas at pfrc.org Thu Feb 13 21:29:17 2014 From: jhaas at pfrc.org (Jeffrey Haas) Date: Thu, 13 Feb 2014 16:29:17 -0500 Subject: Wide BGP Communities update (-04) - input solicited Message-ID: <20140213212916.GK31462@pfrc> The authors of the Wide BGP Communities Internet-draft would like to solicit your feedback on the current version of the draft. The intended purpose of the feature is to provide for next-generation BGP communities. Why "next-generation"? A few motivations: - BGP Path Attribute code space is limited. We want to stop burning new code points for such features when the underlying "mark a route" behavior is the same. - Each time we add something with new encoding, we get deployment lag from needing new code to handle it. - While it's done the job for a number of years, existing communities force operators to go through a lot of convoluted policy to do anything from very common things to subtle things. The accompanying use case document will be updated soon, but not prior to the upcoming IETF. Most of our attention the last few weeks has been on getting the details of the encoding right. In recognition to a very common use case desired here, note Section 5. A wide community is being registered with no further semantics than "here's a list of AS numbers". This permits the desired AS4:AS4 semantic. -- Jeff ----- Forwarded message from internet-drafts at ietf.org ----- Date: Thu, 13 Feb 2014 12:55:54 -0800 From: internet-drafts at ietf.org To: i-d-announce at ietf.org Subject: I-D Action: draft-raszuk-wide-bgp-communities-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Wide BGP Communities Attribute Authors : Robert Raszuk Jeffrey Haas Andrew Lange Shane Amante Bruno Decraene Paul Jakma Richard A Steenbergen Filename : draft-raszuk-wide-bgp-communities-04.txt Pages : 24 Date : 2014-02-13 Abstract: Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. Such information is important to allow BGP speakers to perform some mutually agreed actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From joe at breathe-underwater.com Thu Feb 13 22:28:39 2014 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Thu, 13 Feb 2014 14:28:39 -0800 Subject: Question on Route-Set for Arin DB Message-ID: <43F2033E-0871-422D-B4BE-DA30971615F8@breathe-underwater.com> So the Routing Database is something that I am just learning about and trying to find out if I need to create a Route-set or not. I just created my MNTNER ID and I also created the Route Objects for my two /24s that were given to my by my carriers. Do I need a route-set or aut-num object created? Still trying to get my head wrapped around the need for this. I read through this tutorial: http://www.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf and didn't get a really clear idea as to if I needed these. TIA, Joe From jschiel at flowtools.net Thu Feb 13 18:47:53 2014 From: jschiel at flowtools.net (John) Date: Thu, 13 Feb 2014 11:47:53 -0700 Subject: ddos attack blog In-Reply-To: References: Message-ID: <52FD1359.4020909@flowtools.net> On 02/13/2014 10:06 AM, Cb B wrote: > Good write up, includes name and shame for AT&T Wireless, IIJ, OVH, > DTAG and others > > http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack > > Standard plug for http://openntpproject.org/ and > http://openresolverproject.org/ and bcp38 , please fix/help. > > For those of you paying attention to the outage list, this is a pretty > big deal that has had daily ramification for some very big networks > https://puck.nether.net/pipermail/outages/2014-February/date.html > > In general, i think UDP is doomed to be blocked and rate limited -- > tragedy of the commons. But, it would be nice if folks would just fix > the root of the issue so the rest of us don't have go there... UDP won't be blocked. There are some vendors that have their own hidden protocol inside UDP packets to control and communicate with their devices. Thinking on it again, maybe blocking UDP isn't all that bad. Would force the vendors to not 'hide' their protocol. --John > > Regards, > > CB > From Krishnan.Subramanian at guavus.com Thu Feb 13 19:25:44 2014 From: Krishnan.Subramanian at guavus.com (Krishnan Subramanian) Date: Thu, 13 Feb 2014 19:25:44 +0000 Subject: internet peering conferences in Asia Pacific Message-ID: Does anyone know what is the equivalent or similar conference / organization for Internet operators in Asia Pacific? Thanks, Krishnan From faisal at snappytelecom.net Thu Feb 13 23:30:33 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 13 Feb 2014 23:30:33 +0000 (GMT) Subject: Question on Route-Set for Arin DB In-Reply-To: <43F2033E-0871-422D-B4BE-DA30971615F8@breathe-underwater.com> References: <43F2033E-0871-422D-B4BE-DA30971615F8@breathe-underwater.com> Message-ID: <589090251.699034.1392334233576.JavaMail.root@snappytelecom.net> I am a newbie at it as well, having said that.. the short answer to your question is YES to aut-num and NO to route-set .. but the longer answer will always be based on how you are using the IRR.... If you are doing this for the most common, basic reason, that one of your upstream is requiring it.. then you may have to ask them. (in most cases aut-num for your ASN and route object for your routes is needed at minimum) BTW, I am curious, if you did not create an aut-num object, what did you enter as origin: for your route objects ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Joseph Jenkins" > To: nanog at nanog.org > Sent: Thursday, February 13, 2014 5:28:39 PM > Subject: Question on Route-Set for Arin DB > > So the Routing Database is something that I am just learning about and trying > to find out if I need to create a Route-set or not. I just created my > MNTNER ID and I also created the Route Objects for my two /24s that were > given to my by my carriers. Do I need a route-set or aut-num object > created? > > Still trying to get my head wrapped around the need for this. I read through > this tutorial: > > http://www.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf > > and didn't get a really clear idea as to if I needed these. > > TIA, > > Joe > From wbailey at satelliteintelligencegroup.com Thu Feb 13 23:35:03 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 13 Feb 2014 23:35:03 +0000 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: There is a group called PTC.. Pacific Telecommunications Council.. That?s pretty much the biggest I can think of (lot?s of MSO?s.. Operators, etc.) and it?s in Hawaii every year. On 2/13/14, 11:25 AM, "Krishnan Subramanian" wrote: >Does anyone know what is the equivalent or similar conference / >organization for >Internet operators in Asia Pacific? > >Thanks, >Krishnan > From mehmet at akcin.net Thu Feb 13 23:38:40 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 13 Feb 2014 15:38:40 -0800 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: Apricot Mehmet > On Feb 13, 2014, at 11:25, Krishnan Subramanian wrote: > > Does anyone know what is the equivalent or similar conference / organization for > Internet operators in Asia Pacific? > > Thanks, > Krishnan > From nurul at apnic.net Thu Feb 13 23:40:15 2014 From: nurul at apnic.net (Nurul Islam Roman) Date: Thu, 13 Feb 2014 23:40:15 +0000 Subject: internet peering conferences in Asia Pacific In-Reply-To: Message-ID: http://2014.apricot.net/ -R On 14/02/14 5:25 AM, "Krishnan Subramanian" wrote: >Does anyone know what is the equivalent or similar conference / >organization for >Internet operators in Asia Pacific? > >Thanks, >Krishnan > From geraint at koding.com Thu Feb 13 23:40:29 2014 From: geraint at koding.com (Geraint Jones) Date: Fri, 14 Feb 2014 12:40:29 +1300 Subject: internet peering conferences in Asia Pacific In-Reply-To: Message-ID: http://www.nznog.org/home http://www.ausnog.net/ http://www.sanog.org/ https://www.pacnog.org/ -- Geraint Jones Director of Systems & Infrastructure Koding https://koding.com geraint at koding.com Phone (415) 653-0083 On 14/02/14 8:25 am, "Krishnan Subramanian" wrote: >Does anyone know what is the equivalent or similar conference / >organization for >Internet operators in Asia Pacific? > >Thanks, >Krishnan > From mawatari at jpix.ad.jp Fri Feb 14 00:26:10 2014 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Fri, 14 Feb 2014 09:26:10 +0900 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: <20140214092610.AEEE.8FE1F57E@jpix.ad.jp> APRICOT conference always has time slots of Peering Forum and Peering Cocktail for peering topic. JANOG meeting is held in Japan twice a year. http://www.janog.gr.jp/en/ Regards, Masataka MAWATARI * On Thu, 13 Feb 2014 23:40:15 +0000 * Nurul Islam Roman wrote: > http://2014.apricot.net/ > > -R > > On 14/02/14 5:25 AM, "Krishnan Subramanian" > wrote: > > >Does anyone know what is the equivalent or similar conference / > >organization for > >Internet operators in Asia Pacific? > > > >Thanks, > >Krishnan From jared at puck.nether.net Fri Feb 14 01:01:27 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 13 Feb 2014 20:01:27 -0500 Subject: ddos attack blog In-Reply-To: <52FD1359.4020909@flowtools.net> References: <52FD1359.4020909@flowtools.net> Message-ID: On Feb 13, 2014, at 1:47 PM, John wrote: > On 02/13/2014 10:06 AM, Cb B wrote: >> Good write up, includes name and shame for AT&T Wireless, IIJ, OVH, >> DTAG and others >> >> http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack >> >> Standard plug for http://openntpproject.org/ and >> http://openresolverproject.org/ and bcp38 , please fix/help. >> >> For those of you paying attention to the outage list, this is a pretty >> big deal that has had daily ramification for some very big networks >> https://puck.nether.net/pipermail/outages/2014-February/date.html >> >> In general, i think UDP is doomed to be blocked and rate limited -- >> tragedy of the commons. But, it would be nice if folks would just fix >> the root of the issue so the rest of us don't have go there... > > UDP won't be blocked. There are some vendors that have their own hidden protocol inside UDP packets to control and communicate with their devices. > > Thinking on it again, maybe blocking UDP isn't all that bad. Would force the vendors to not 'hide' their protocol. > Be careful what you wish for. I know some people have just blocked all NTP to keep their servers from participating in attacks. This is common in places where they hand off a VM/host to a customer and no longer have access despite it being in their environment. I would actually like to ask for those folks to un-block NTP so there is proper data on the number of hosts for those researching this. The right thing to do is reconfigure them. I've seen a good trend line in NTP servers being fixed, and hope we will see more of that in the next few weeks. I've seen maybe 100-200 per-ASN reports handed out to network operators. If you want yours, please e-mail ntp-scan at puck.nether.net to obtain it. Put your ASN in the subject line and/or body. - Jared (and others like Patrick that presented on the projects behalf). From randy at psg.com Fri Feb 14 01:34:19 2014 From: randy at psg.com (Randy Bush) Date: Fri, 14 Feb 2014 10:34:19 +0900 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: > There is a group called PTC the T stands for telco. no internet peering From ttauber at 1-4-5.net Fri Feb 14 03:12:54 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 13 Feb 2014 22:12:54 -0500 Subject: Question on Route-Set for Arin DB In-Reply-To: <589090251.699034.1392334233576.JavaMail.root@snappytelecom.net> References: <43F2033E-0871-422D-B4BE-DA30971615F8@breathe-underwater.com> <589090251.699034.1392334233576.JavaMail.root@snappytelecom.net> Message-ID: The origin stands alone; no aut-num needed in many cases. The way many providers use the IRR info is to take the adjacent ASN and do a reverse index lookup on the origin field. That is, for AS1234, what are all the route and route6 objects with that as an origin. If you need something more complicated, you can use an aut-num object to say that an as-set, route-set or combinations of these ought to be folded in when creating the filters. Tony On Thu, Feb 13, 2014 at 6:30 PM, Faisal Imtiaz wrote: > I am a newbie at it as well, having said that.. the short answer to your > question is YES to aut-num and NO to route-set .. > but the longer answer will always be based on how you are using the IRR.... > > If you are doing this for the most common, basic reason, that one of your > upstream is requiring it.. then you may have to ask them. > (in most cases aut-num for your ASN and route object for your routes is > needed at minimum) > > BTW, I am curious, if you did not create an aut-num object, what did you > enter as origin: for your route objects ? > > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Joseph Jenkins" > > To: nanog at nanog.org > > Sent: Thursday, February 13, 2014 5:28:39 PM > > Subject: Question on Route-Set for Arin DB > > > > So the Routing Database is something that I am just learning about and > trying > > to find out if I need to create a Route-set or not. I just created my > > MNTNER ID and I also created the Route Objects for my two /24s that were > > given to my by my carriers. Do I need a route-set or aut-num object > > created? > > > > Still trying to get my head wrapped around the need for this. I read > through > > this tutorial: > > > > > http://www.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf > > > > and didn't get a really clear idea as to if I needed these. > > > > TIA, > > > > Joe > > > > From wbailey at satelliteintelligencegroup.com Fri Feb 14 04:09:22 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 14 Feb 2014 04:09:22 +0000 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: , Message-ID: Simmer. http://www.iixpeering.net/news/iix-leads-remote-peering-industry-at-ptc-14/ ... Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Randy Bush Date: 02/13/2014 5:34 PM (GMT-08:00) To: Warren Bailey Cc: Krishnan Subramanian ,nanog at nanog.org Subject: Re: internet peering conferences in Asia Pacific > There is a group called PTC the T stands for telco. no internet peering From wbailey at satelliteintelligencegroup.com Fri Feb 14 04:11:25 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 14 Feb 2014 04:11:25 +0000 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: , Message-ID: <3f6fqct0ik69so32pyce9w8y.1392351081567@email.android.com> https://www.ams-ix.net/events/19 In case more citation is required. I'd imagine the whole "free trip to hawaii" aspect brings in more folks than you'd expect. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Randy Bush Date: 02/13/2014 5:34 PM (GMT-08:00) To: Warren Bailey Cc: Krishnan Subramanian ,nanog at nanog.org Subject: Re: internet peering conferences in Asia Pacific > There is a group called PTC the T stands for telco. no internet peering From randy at psg.com Fri Feb 14 04:13:05 2014 From: randy at psg.com (Randy Bush) Date: Fri, 14 Feb 2014 13:13:05 +0900 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: > http://www.iixpeering.net/news/iix-leads-remote-peering-industry-at-ptc-14/ ah yes, sales and marketing bumph. desperate for any venue. the point is, if you want to do internet peering in asia, the venues are apricot, sanog, aus/nz/.../nog, ripe (yes, asian peering coords go to ripe), etc. randy From randy at psg.com Fri Feb 14 05:24:54 2014 From: randy at psg.com (Randy Bush) Date: Fri, 14 Feb 2014 14:24:54 +0900 Subject: Question on Route-Set for Arin DB In-Reply-To: References: <43F2033E-0871-422D-B4BE-DA30971615F8@breathe-underwater.com> <589090251.699034.1392334233576.JavaMail.root@snappytelecom.net> Message-ID: > The way many providers use the IRR info is to take the adjacent ASN and do > a reverse index lookup on the origin field. > That is, for AS1234, what are all the route and route6 objects with that as > an origin. > If you need something more complicated, you can use an aut-num object to > say that an as-set, route-set or combinations of these ought to be folded > in when creating the filters. fwiw, i build filters by running peval() over their as-set randy From tony at lavanauts.org Fri Feb 14 05:44:23 2014 From: tony at lavanauts.org (Antonio Querubin) Date: Thu, 13 Feb 2014 19:44:23 -1000 (HST) Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: On Thu, 13 Feb 2014, Warren Bailey wrote: > There is a group called PTC.. Pacific Telecommunications Council.. That?s > pretty much the biggest I can think of (lot?s of MSO?s.. Operators, etc.) > and it?s in Hawaii every year. Actually the conference moves around the Pacific. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From mark.tinka at seacom.mu Fri Feb 14 05:56:41 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 14 Feb 2014 07:56:41 +0200 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: <201402140756.42179.mark.tinka@seacom.mu> On Friday, February 14, 2014 01:35:03 AM Warren Bailey wrote: > There is a group called PTC.. Pacific Telecommunications > Council.. That?s pretty much the biggest I can think of > (lot?s of MSO?s.. Operators, etc.) and it?s in Hawaii > every year. PTC is not your typical "-NOG" or "-PF" forum. It's very salesy in nature and revolves around operators scheduling meetings in hotel suites on an hourly basis to talk commercial matters, not necessarily peering and operations a la "-NOG's" and "-PF's". If you've been to a Capacity Pick-Your-Region meeting, PTC is like that. Just bigger. The plenaries at PTC are poorly attended (IMHO), quite costly, and the content is not the kind you would find at NANOG, APRICOT, RIPE, APF, GPF, AfPIF, e.t.c. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From randy at psg.com Fri Feb 14 06:19:52 2014 From: randy at psg.com (Randy Bush) Date: Fri, 14 Feb 2014 15:19:52 +0900 Subject: ARIN Wants Your Feedback In-Reply-To: <20140212194427.9D68F165D45@smtp1.arin.net> References: <20140212194427.9D68F165D45@smtp1.arin.net> Message-ID: the survey questions are highly biased toward arin's view of itself. just one example. you ask how well arin serves it's members and customers. you do not ask how well it serves the internet community, the internet, or society in general. and that particular bias in viewpoint is at the core of arin's failure. randy From snoble at sonn.com Fri Feb 14 06:29:45 2014 From: snoble at sonn.com (Steve Noble) Date: Thu, 13 Feb 2014 22:29:45 -0800 Subject: ARIN Wants Your Feedback In-Reply-To: References: <20140212194427.9D68F165D45@smtp1.arin.net> Message-ID: I answered it truthfully, I clicked a lot of 1s. On Feb 13, 2014 10:21 PM, "Randy Bush" wrote: > the survey questions are highly biased toward arin's view of itself. > just one example. you ask how well arin serves it's members and > customers. you do not ask how well it serves the internet community, > the internet, or society in general. and that particular bias in > viewpoint is at the core of arin's failure. > > randy > > From randy at psg.com Fri Feb 14 06:39:04 2014 From: randy at psg.com (Randy Bush) Date: Fri, 14 Feb 2014 15:39:04 +0900 Subject: ARIN Wants Your Feedback In-Reply-To: References: <20140212194427.9D68F165D45@smtp1.arin.net> Message-ID: > I answered it truthfully, I clicked a lot of 1s. i actually find day-to-day transactions with hostfolk ok. the org just has no vision of the internet. register, do not regulate. board, ceo, and AC seem to be dominated by itu wannabes. randy From owen at delong.com Fri Feb 14 07:15:22 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Feb 2014 23:15:22 -0800 Subject: ARIN Wants Your Feedback In-Reply-To: References: <20140212194427.9D68F165D45@smtp1.arin.net> Message-ID: On Feb 13, 2014, at 10:39 PM, Randy Bush wrote: >> I answered it truthfully, I clicked a lot of 1s. > > i actually find day-to-day transactions with hostfolk ok. the org just > has no vision of the internet. register, do not regulate. board, ceo, > and AC seem to be dominated by itu wannabes. > > randy An interesting comment given that we currently do a lot more of the former and a lot less of the latter than what ARIN did when you were on the AC. Owen From mark.tinka at seacom.mu Fri Feb 14 08:10:37 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 14 Feb 2014 10:10:37 +0200 Subject: ddos attack blog In-Reply-To: References: <52FD1359.4020909@flowtools.net> Message-ID: <201402141010.40837.mark.tinka@seacom.mu> On Friday, February 14, 2014 03:01:27 AM Jared Mauch wrote: > I would actually like to ask for those folks to un-block > NTP so there is proper data on the number of hosts for > those researching this. The right thing to do is > reconfigure them. I've seen a good trend line in NTP > servers being fixed, and hope we will see more of that > in the next few weeks. Depending on your OS, the fixes can be quite simple or interesting. On my FreeBSD servers, simply updating with "freebsd-update" was enough to fix the issue (in addition to limiting who/what can access the service). On Cisco devices, the ACL's you can attach to the NTP process are quite effective. On Juniper devices, it is less intuitive, and even though NTP is enabled only as a client, it, sadly, runs the server as well. A firewall filter helps here when applied correctly. Can't speak to other OS's. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From patrick at ianai.net Fri Feb 14 10:11:07 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 14 Feb 2014 05:11:07 -0500 Subject: internet peering conferences in Asia Pacific In-Reply-To: References: Message-ID: <86C7FFF5-9FAC-49E5-AAFC-BDDE5BA319F9@ianai.net> On Feb 14, 2014, at 00:44 , Antonio Querubin wrote: > On Thu, 13 Feb 2014, Warren Bailey wrote: >> There is a group called PTC.. Pacific Telecommunications Council.. That?s >> pretty much the biggest I can think of (lot?s of MSO?s.. Operators, etc.) >> and it?s in Hawaii every year. > > Actually the conference moves around the Pacific. When was the last time it was not in Honolulu? -- TTFN, patrick From jcurran at arin.net Fri Feb 14 16:10:43 2014 From: jcurran at arin.net (John Curran) Date: Fri, 14 Feb 2014 16:10:43 +0000 Subject: ARIN Wants Your Feedback In-Reply-To: References: <20140212194427.9D68F165D45@smtp1.arin.net> Message-ID: <4AD3D012-1F5D-4DD1-9277-AB001C46E3F3@arin.net> On Feb 14, 2014, at 1:19 AM, Randy Bush wrote: > the survey questions are highly biased toward arin's view of itself. > just one example. you ask how well arin serves it's members and > customers. you do not ask how well it serves the internet community, > the internet, or society in general. and that particular bias in > viewpoint is at the core of arin's failure. Randy - Thanks for the feedback! We'd like to keep the questions consistent to readily support year-over-year comparisons, but adding several questions regarding ARIN's service to the Internet and society is excellent idea that we should be able to accommodate next time around. Thanks! /John John Curran President and CEO ARIN From george.herbert at gmail.com Fri Feb 14 17:08:51 2014 From: george.herbert at gmail.com (George William Herbert) Date: Fri, 14 Feb 2014 09:08:51 -0800 Subject: ARIN Wants Your Feedback In-Reply-To: References: <20140212194427.9D68F165D45@smtp1.arin.net> Message-ID: Gentlemen! Cease this infernal internal bickering! If we do not make common cause against the one true enemy, the User, all is lost! ... -george william herbert george.herbert at gmail.com Sent from Kangphone On Feb 13, 2014, at 11:15 PM, Owen DeLong wrote: > > On Feb 13, 2014, at 10:39 PM, Randy Bush wrote: > >>> I answered it truthfully, I clicked a lot of 1s. >> >> i actually find day-to-day transactions with hostfolk ok. the org just >> has no vision of the internet. register, do not regulate. board, ceo, >> and AC seem to be dominated by itu wannabes. >> >> randy > > An interesting comment given that we currently do a lot more of the former and a lot less of the latter than what ARIN did when you were on the AC. > > Owen > > From braymo at llnw.com Fri Feb 14 17:13:23 2014 From: braymo at llnw.com (Bradley Raymo) Date: Fri, 14 Feb 2014 12:13:23 -0500 Subject: internet peering conferences in Asia Pacific In-Reply-To: <86C7FFF5-9FAC-49E5-AAFC-BDDE5BA319F9@ianai.net> References: <86C7FFF5-9FAC-49E5-AAFC-BDDE5BA319F9@ianai.net> Message-ID: Asian Peering Forum. [image: Limelight Networks] Bradley Raymo - Senior Network Planner *p:* +1 602 850 5716 | *m: *+1 623 703 5300 [image: Show It. Tell It. Every. Way. Every. Where.] www.limelight.com [image: Facebook] [image: LinkedIn] [image: Twitter] On Fri, Feb 14, 2014 at 5:11 AM, Patrick W. Gilmore wrote: > On Feb 14, 2014, at 00:44 , Antonio Querubin wrote: > > On Thu, 13 Feb 2014, Warren Bailey wrote: > > >> There is a group called PTC.. Pacific Telecommunications Council.. > That?s > >> pretty much the biggest I can think of (lot?s of MSO?s.. Operators, > etc.) > >> and it?s in Hawaii every year. > > > > Actually the conference moves around the Pacific. > > When was the last time it was not in Honolulu? > > -- > TTFN, > patrick > > > From cscora at apnic.net Fri Feb 14 18:13:01 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Feb 2014 04:13:01 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201402141813.s1EID1eu001024@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Feb, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 482175 Prefixes after maximum aggregation: 191598 Deaggregation factor: 2.52 Unique aggregates announced to Internet: 238436 Total ASes present in the Internet Routing Table: 46178 Prefixes per ASN: 10.44 Origin-only ASes present in the Internet Routing Table: 35615 Origin ASes announcing only one prefix: 16407 Transit ASes present in the Internet Routing Table: 6027 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1880 Unregistered ASNs in the Routing Table: 492 Number of 32-bit ASNs allocated by the RIRs: 5941 Number of 32-bit ASNs visible in the Routing Table: 4536 Prefixes from 32-bit ASNs in the Routing Table: 14493 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 428 Number of addresses announced to Internet: 2655149028 Equivalent to 158 /8s, 66 /16s and 91 /24s Percentage of available address space announced: 71.7 Percentage of allocated address space announced: 71.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.7 Total number of prefixes smaller than registry allocations: 168252 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 114345 Total APNIC prefixes after maximum aggregation: 34516 APNIC Deaggregation factor: 3.31 Prefixes being announced from the APNIC address blocks: 116873 Unique aggregates announced from the APNIC address blocks: 49142 APNIC Region origin ASes present in the Internet Routing Table: 4893 APNIC Prefixes per ASN: 23.89 APNIC Region origin ASes announcing only one prefix: 1223 APNIC Region transit ASes present in the Internet Routing Table: 841 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 21 Number of APNIC region 32-bit ASNs visible in the Routing Table: 834 Number of APNIC addresses announced to Internet: 730899008 Equivalent to 43 /8s, 144 /16s and 162 /24s Percentage of available APNIC address space announced: 85.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 165163 Total ARIN prefixes after maximum aggregation: 82672 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 166487 Unique aggregates announced from the ARIN address blocks: 77076 ARIN Region origin ASes present in the Internet Routing Table: 16142 ARIN Prefixes per ASN: 10.31 ARIN Region origin ASes announcing only one prefix: 6101 ARIN Region transit ASes present in the Internet Routing Table: 1681 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 66 Number of ARIN addresses announced to Internet: 1064975232 Equivalent to 63 /8s, 122 /16s and 59 /24s Percentage of available ARIN address space announced: 56.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 121470 Total RIPE prefixes after maximum aggregation: 61741 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 125413 Unique aggregates announced from the RIPE address blocks: 79964 RIPE Region origin ASes present in the Internet Routing Table: 17642 RIPE Prefixes per ASN: 7.11 RIPE Region origin ASes announcing only one prefix: 8328 RIPE Region transit ASes present in the Internet Routing Table: 2860 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2620 Number of RIPE addresses announced to Internet: 656547716 Equivalent to 39 /8s, 34 /16s and 31 /24s Percentage of available RIPE address space announced: 95.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 54496 Total LACNIC prefixes after maximum aggregation: 9994 LACNIC Deaggregation factor: 5.45 Prefixes being announced from the LACNIC address blocks: 60180 Unique aggregates announced from the LACNIC address blocks: 27714 LACNIC Region origin ASes present in the Internet Routing Table: 2065 LACNIC Prefixes per ASN: 29.14 LACNIC Region origin ASes announcing only one prefix: 550 LACNIC Region transit ASes present in the Internet Routing Table: 411 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1007 Number of LACNIC addresses announced to Internet: 150817696 Equivalent to 8 /8s, 253 /16s and 75 /24s Percentage of available LACNIC address space announced: 89.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12093 Total AfriNIC prefixes after maximum aggregation: 2637 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 12794 Unique aggregates announced from the AfriNIC address blocks: 4184 AfriNIC Region origin ASes present in the Internet Routing Table: 705 AfriNIC Prefixes per ASN: 18.15 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 148 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 9 Number of AfriNIC addresses announced to Internet: 51488000 Equivalent to 3 /8s, 17 /16s and 165 /24s Percentage of available AfriNIC address space announced: 51.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2978 11564 892 Korea Telecom 17974 2756 902 88 PT Telekomunikasi Indonesia 7545 2183 320 116 TPG Telecom Limited 4755 1822 392 194 TATA Communications formerly 9829 1592 1283 39 National Internet Backbone 9583 1300 102 533 Sify Limited 7552 1232 1082 13 Viettel Corporation 4808 1169 2117 355 CNCGROUP IP network China169 24560 1104 376 172 Bharti Airtel Ltd., Telemedia 9498 1083 293 66 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3025 3688 53 BellSouth.net Inc. 22773 2323 2938 139 Cox Communications Inc. 1785 2163 691 129 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1684 1665 572 Charter Communications 4323 1620 1090 412 tw telecom holdings, inc. 701 1492 11189 761 MCI Communications Services, 30036 1359 291 572 Mediacom Communications Corp 6983 1298 772 582 ITC^Deltacom 7018 1294 18003 838 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1794 544 16 OJSC "Vimpelcom" 34984 1402 243 225 TELLCOM ILETISIM HIZMETLERI A 20940 1229 456 922 Akamai International B.V. 13188 1046 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 895 370 41 Bezeq International-Ltd 6849 859 362 37 JSC "Ukrtelecom" 6830 773 2331 424 Liberty Global Operations B.V 12479 710 797 55 France Telecom Espana SA 35228 553 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3412 1882 80 NET Servi?os de Comunica??o S 10620 2738 439 199 Telmex Colombia S.A. 18881 1875 972 21 Global Village Telecom 7303 1744 1165 220 Telecom Argentina S.A. 8151 1377 2892 422 Uninet S.A. de C.V. 6503 930 434 61 Axtel, S.A.B. de C.V. 11830 869 364 15 Instituto Costarricense de El 7738 847 1626 39 Telemar Norte Leste S.A. 27947 842 93 88 Telconet S.A 3816 770 314 132 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1810 240 6 Sudanese Mobile Telephone (ZA 24863 917 380 28 Link Egypt (Link.NET) 6713 602 685 28 Office National des Postes et 8452 485 958 13 TE-AS 24835 298 144 9 Vodafone Data 36992 263 783 24 ETISALAT MISR 29571 248 22 17 Cote d'Ivoire Telecom 3741 247 921 208 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3412 1882 80 NET Servi?os de Comunica??o S 6389 3025 3688 53 BellSouth.net Inc. 4766 2978 11564 892 Korea Telecom 17974 2756 902 88 PT Telekomunikasi Indonesia 10620 2738 439 199 Telmex Colombia S.A. 22773 2323 2938 139 Cox Communications Inc. 7545 2183 320 116 TPG Telecom Limited 1785 2163 691 129 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1875 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3025 2972 BellSouth.net Inc. 17974 2756 2668 PT Telekomunikasi Indonesia 10620 2738 2539 Telmex Colombia S.A. 22773 2323 2184 Cox Communications Inc. 4766 2978 2086 Korea Telecom 7545 2183 2067 TPG Telecom Limited 1785 2163 2034 PaeTec Communications, Inc. 18566 2048 1870 MegaPath Corporation 18881 1875 1854 Global Village Telecom 36998 1810 1804 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 41.73.18.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:30 /11:90 /12:254 /13:476 /14:953 /15:1660 /16:12874 /17:6826 /18:11521 /19:23755 /20:33449 /21:36100 /22:51557 /23:44857 /24:255554 /25:775 /26:933 /27:434 /28:12 /29:17 /30:8 /31:1 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 36998 1771 1810 Sudanese Mobile Telephone (ZA 6389 1696 3025 BellSouth.net Inc. 22773 1567 2323 Cox Communications Inc. 8402 1474 1794 OJSC "Vimpelcom" 30036 1199 1359 Mediacom Communications Corp 11492 1162 1200 CABLE ONE, INC. 1785 1160 2163 PaeTec Communications, Inc. 6983 1038 1298 ITC^Deltacom 22561 990 1276 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:945 2:793 3:3 4:16 5:896 6:22 8:656 12:1857 13:3 14:950 15:9 16:3 17:24 18:21 20:36 23:679 24:1709 27:1730 31:1559 32:44 33:2 34:5 36:122 37:1923 38:928 39:4 40:192 41:3293 42:243 44:17 46:2131 47:12 49:664 50:918 52:12 54:56 55:3 57:26 58:1138 59:582 60:370 61:1512 62:1241 63:1963 64:4371 65:2253 66:4190 67:2060 68:1027 69:3303 70:858 71:472 72:2010 74:2658 75:313 76:309 77:1186 78:1041 79:696 80:1319 81:1121 82:672 83:740 84:758 85:1250 86:422 87:1032 88:520 89:1658 90:146 91:5727 92:667 93:1648 94:1976 95:1444 96:531 97:353 98:1067 99:41 100:34 101:772 103:4181 105:536 106:148 107:464 108:538 109:2084 110:968 111:1248 112:618 113:821 114:781 115:1069 116:1024 117:869 118:1262 119:1302 120:331 121:787 122:1934 123:1255 124:1395 125:1407 128:638 129:242 130:365 131:658 132:353 133:157 134:313 135:74 136:249 137:301 138:350 139:156 140:206 141:359 142:552 143:414 144:491 145:99 146:598 147:412 148:788 149:342 150:149 151:559 152:422 153:205 154:82 155:524 156:325 157:367 158:293 159:861 160:357 161:464 162:1139 163:215 164:677 165:605 166:290 167:591 168:1047 169:125 170:1183 171:196 172:15 173:1599 174:677 175:570 176:1438 177:2738 178:1975 179:450 180:1626 181:988 182:1376 183:497 184:691 185:1264 186:2798 187:1461 188:1972 189:1286 190:7436 191:72 192:7094 193:5429 194:4002 195:3364 196:1369 197:1099 198:4902 199:5572 200:6080 201:2608 202:8988 203:8902 204:4489 205:2657 206:2927 207:2869 208:3962 209:3656 210:3101 211:1663 212:2222 213:2027 214:881 215:84 216:5504 217:1700 218:570 219:323 220:1291 221:593 222:336 223:589 End of report From rnalrd at gmail.com Fri Feb 14 18:19:44 2014 From: rnalrd at gmail.com (Leonardo Arena) Date: Fri, 14 Feb 2014 19:19:44 +0100 Subject: Yahoo mail contacts Message-ID: <1392401984.8581.6.camel@c89m3s1> Hi, I've been trying contacting Yahoo Email support in Europe through the web support page in vain. Apparently they are all busy in moving their EMEA HQ... :) If there's anyone from Yahoo Mail that read this list that can contact me off-list I'd be grateful. Thank you in advance. - leonardo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From web at typo.org Fri Feb 14 18:22:29 2014 From: web at typo.org (Wayne E Bouchard) Date: Fri, 14 Feb 2014 11:22:29 -0700 Subject: ddos attack blog In-Reply-To: References: <52FD1359.4020909@flowtools.net> Message-ID: <20140214182229.GA34161@wakko.typo.org> On Thu, Feb 13, 2014 at 08:01:27PM -0500, Jared Mauch wrote: > I would actually like to ask for those folks to un-block NTP so there is proper data on the number of hosts for those researching this. The right thing to do is reconfigure them. I've seen a good trend line in NTP servers being fixed, and hope we will see more of that in the next few weeks. A slight exception to that statement, if I may... The right thing to do is for people to not permit services to operate on hosts they do not intend to operate on and not to be visible to those they do not intend to use them. In other words, to properly manage their networks. If that means blocking all access to potentially faulty implementations, then that's the right thing to do. In short, companies should do what is right for their companies and nevermind anyone else. Never forget that researches are just part of the "public" and should never consider that their usage of the internet is any more or less valid to the average third party than the next guy. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From fergdawgster at mykolab.com Fri Feb 14 18:42:55 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 14 Feb 2014 10:42:55 -0800 Subject: Permitting spoofed traffic [Was: Re: ddos attack blog] In-Reply-To: <20140214182229.GA34161@wakko.typo.org> References: <52FD1359.4020909@flowtools.net> <20140214182229.GA34161@wakko.typo.org> Message-ID: <52FE63AF.8010800@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/14/2014 10:22 AM, Wayne E Bouchard wrote: > On Thu, Feb 13, 2014 at 08:01:27PM -0500, Jared Mauch wrote: >> I would actually like to ask for those folks to un-block NTP so >> there is proper data on the number of hosts for those researching >> this. The right thing to do is reconfigure them. I've seen a >> good trend line in NTP servers being fixed, and hope we will see >> more of that in the next few weeks. > > > A slight exception to that statement, if I may... > > The right thing to do is for people to not permit services to > operate on hosts they do not intend to operate on and not to be > visible to those they do not intend to use them. In other words, to > properly manage their networks. If that means blocking all access > to potentially faulty implementations, then that's the right thing > to do. In short, companies should do what is right for their > companies and nevermind anyone else. > > Never forget that researches are just part of the "public" and > should never consider that their usage of the internet is any more > or less valid to the average third party than the next guy. > Taken to the logical extreme, the "right thing" to do is to deny any spoofed traffic from abusing these services altogether. NTP is not the only one; there is also SNMP, DNS, etc. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL+Y68ACgkQKJasdVTchbJ/dgEAqgERvP6HMl2v5fbhZDwI9QKT YEe/c3mN5gZlxsIKFo0A/3BH9KMV6ln7XMrlnk4c/GuwZ9X4LAgqO6l2p8u3aA49 =yWZU -----END PGP SIGNATURE----- From jschiel at flowtools.net Fri Feb 14 18:51:21 2014 From: jschiel at flowtools.net (John) Date: Fri, 14 Feb 2014 11:51:21 -0700 Subject: ddos attack blog In-Reply-To: References: <52FD1359.4020909@flowtools.net> Message-ID: <52FE65A9.9000404@flowtools.net> On 02/13/2014 06:01 PM, Jared Mauch wrote: > On Feb 13, 2014, at 1:47 PM, John wrote: > UDP won't be blocked. There are some vendors that have their own hidden protocol inside UDP packets to control and communicate with their devices. > > Thinking on it again, maybe blocking UDP isn't all that bad. Would force the vendors to not 'hide' their protocol. > > Be careful what you wish for. I know some people have just blocked all NTP to keep their servers from participating in attacks. This is common in places where they hand off a VM/host to a customer and no longer have access despite it being in their environment. I was being a bit extreme, I don't expect UDP to be blocked and there are valid uses for NTP and it needs to pass. Can you imagine the trading servers not having access to NTP? The knee jerk reaction to just block NTP is a temporary measure that can be used while other mitigation steps are implemented. I kinda hijacked the NTP issue a bit and expanded it to cover the undocumented uses of device control in UDP. I'll leave that issue for another day, just wanted to raise awareness if it was not already known. --John > I would actually like to ask for those folks to un-block NTP so there is proper data on the number of hosts for those researching this. The right thing to do is reconfigure them. I've seen a good trend line in NTP servers being fixed, and hope we will see more of that in the next few weeks. > > I've seen maybe 100-200 per-ASN reports handed out to network operators. If you want yours, please e-mail ntp-scan at puck.nether.net to obtain it. Put your ASN in the subject line and/or body. > > - Jared (and others like Patrick that presented on the projects behalf). > From cidr-report at potaroo.net Fri Feb 14 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Feb 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201402142200.s1EM00gZ030806@wattle.apnic.net> This report has been generated at Fri Feb 14 21:13:40 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-02-14 492404 276396 08-02-14 492610 276243 09-02-14 492494 276275 10-02-14 492960 276542 11-02-14 493183 276733 12-02-14 493377 276862 13-02-14 493447 277231 14-02-14 493241 277589 AS Summary 46351 Number of ASes in routing system 19012 Number of ASes announcing only one prefix 4468 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 119624960 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 14Feb14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 493996 277576 216420 43.8% All ASes AS28573 3449 83 3366 97.6% NET Servi?os de Comunica??o S.A. AS6389 3025 56 2969 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 4468 1718 2750 61.5% WINDSTREAM - Windstream Communications Inc AS17974 2755 210 2545 92.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 2327 233 2094 90.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2978 901 2077 69.7% KIXS-AS-KR Korea Telecom AS18881 1875 36 1839 98.1% Global Village Telecom AS1785 2163 406 1757 81.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS36998 1810 158 1652 91.3% SDN-MOBITEL AS10620 2739 1174 1565 57.1% Telmex Colombia S.A. AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2927 1515 1412 48.2% TWTC - tw telecom holdings, inc. AS7303 1745 432 1313 75.2% Telecom Argentina S.A. AS4755 1823 589 1234 67.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1257 158 1099 87.4% VIETEL-AS-AP Viettel Corporation AS7545 2186 1112 1074 49.1% TPG-INTERNET-AP TPG Telecom Limited AS22561 1276 227 1049 82.2% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1592 652 940 59.0% BSNL-NIB National Internet Backbone AS18101 993 187 806 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1169 394 775 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS35908 864 102 762 88.2% VPLSNET - Krypt Technologies AS24560 1104 372 732 66.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS701 1492 761 731 49.0% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1386 664 722 52.1% Uninet S.A. de C.V. AS6983 1299 582 717 55.2% ITCDELTA - ITC^Deltacom AS4788 960 254 706 73.5% TMNET-AS-AP TM Net, Internet Service Provider AS7738 847 148 699 82.5% Telemar Norte Leste S.A. AS855 748 56 692 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 1029 373 656 63.8% SEEDNET Digital United Inc. AS6147 766 113 653 85.2% Telefonica del Peru S.A.A. Total 55099 14231 40868 74.2% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.193.176.0/22 AS42842 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.211.76.0/22 AS42842 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.220.176.0/24 AS16265 FIBERRING LeaseWeb B.V. 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 109.197.200.0/21 AS42842 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 151.216.128.0/17 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.87.0.0/24 AS29571 CITelecom-AS 172.88.0.0/24 AS29571 CITelecom-AS 172.89.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.28.14.0/24 AS34309 LINK11 Link11 GmbH 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.33.252.0/23 AS3356 LEVEL3 Level 3 Communications 193.38.144.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd 193.84.187.0/24 AS16276 OVH OVH Systems 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.52.0/23 AS16276 OVH OVH Systems 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.121.0/24 AS9143 ZIGGO Ziggo B.V. 193.227.129.0/24 AS8990 AHRT-AS "ANTENNA HUNGARIA" Magyar Musorszoro es Radiohirkozlesi Zartkoruen Mukodo Reszvenytarsasag 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd. 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.50.82.0/24 AS16276 OVH OVH Systems 194.55.104.0/23 AS7244 ALAMEDANET - Alameda Networks 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB 194.156.179.0/24 AS3209 VODANET Vodafone GmbH 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.28.168.0/23 AS8655 195.64.128.0/23 AS8751 MEDIASAT Media Sat SRL 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 FIBERRING LeaseWeb B.V. 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.178.120.0/23 AS39385 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 14 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Feb 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201402142200.s1EM01le030820@wattle.apnic.net> BGP Update Report Interval: 06-Feb-14 -to- 13-Feb-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7315 78341 3.0% 1135.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 2 - AS9829 65089 2.5% 69.1 -- BSNL-NIB National Internet Backbone 3 - AS60349 61389 2.4% 959.2 -- PBL-KIEV-AS Partners. Business & Law Ltd. 4 - AS34875 50299 1.9% 378.2 -- YANFES OJSC "Rostelecom" 5 - AS35181 43614 1.7% 14538.0 -- PWC Autonomous System Number for Public WareHouse Company 6 - AS8402 32284 1.2% 33.2 -- CORBINA-AS OJSC "Vimpelcom" 7 - AS31148 26886 1.0% 26.4 -- FREENET-AS Freenet Ltd. 8 - AS41691 26877 1.0% 959.9 -- SUMTEL-AS-RIPE Summa Telecom LLC 9 - AS28573 23735 0.9% 14.5 -- NET Servi?os de Comunica??o S.A. 10 - AS13118 20558 0.8% 514.0 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS4775 18880 0.7% 349.6 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS18747 17337 0.7% 52.1 -- 13 - AS27738 13970 0.5% 24.2 -- Ecuadortelecom S.A. 14 - AS8151 13211 0.5% 11.7 -- Uninet S.A. de C.V. 15 - AS28024 13187 0.5% 19.7 -- Nuevatel PCS de Bolivia S.A. 16 - AS45899 12840 0.5% 31.1 -- VNPT-AS-VN VNPT Corp 17 - AS18881 12398 0.5% 14.5 -- Global Village Telecom 18 - AS11492 12306 0.5% 17.5 -- CABLEONE - CABLE ONE, INC. 19 - AS11976 11619 0.5% 252.6 -- FIDN - Fidelity Communication International Inc. 20 - AS647 11471 0.4% 85.6 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35181 43614 1.7% 14538.0 -- PWC Autonomous System Number for Public WareHouse Company 2 - AS6459 7725 0.3% 7725.0 -- TRANSBEAM - I-2000, Inc. 3 - AS54465 6622 0.3% 6622.0 -- QPM-AS-1 - QuickPlay Media Inc. 4 - AS59217 4975 0.2% 4975.0 -- AZONNELIMITED-AS-AP Azonne Limited 5 - AS27505 2938 0.1% 2938.0 -- DARK-PALADIN - Dark Paladin Productions 6 - AS39575 2626 0.1% 2626.0 -- SIBINTEK-SAMARA-AS Siberian Internet Company 7 - AS45055 2026 0.1% 2026.0 -- DONTECHSVYAZ Dontechsvyaz, private joint stock company 8 - AS6629 8903 0.3% 1780.6 -- NOAA-AS - NOAA 9 - AS14287 10620 0.4% 1770.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 10 - AS51075 1390 0.1% 1390.0 -- WOLFF-PL WYDAWNICTWO MULTIMEDIALNE KOWALEWSKI I WOLFF SPOLKA CYWILNA PIOTR GLADKI KRZYSZTOF KOWALEWSKI MACIEJ MANSKI 11 - AS38491 2768 0.1% 1384.0 -- BSP-AS-AP Bangko Sentral ng Pilipinas, Manila, Philippines 12 - AS62431 1288 0.1% 1288.0 -- NCSC-IE-AS National Cyber Security Centre 13 - AS7315 78341 3.0% 1135.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 14 - AS37546 1065 0.0% 1065.0 -- MIA-TELECOMs 15 - AS12922 1025 0.0% 1025.0 -- MULTITRADE-AS CEDACRI S.P.A. 16 - AS41691 26877 1.0% 959.9 -- SUMTEL-AS-RIPE Summa Telecom LLC 17 - AS60349 61389 2.4% 959.2 -- PBL-KIEV-AS Partners. Business & Law Ltd. 18 - AS40524 1911 0.1% 955.5 -- FUNSOFT-AS - Fundamental Software, Inc. 19 - AS11486 7082 0.3% 885.2 -- COLO-PREM-VZB - Verizon Online LLC 20 - AS57201 842 0.0% 842.0 -- EDF-AS Estonian Defence Forces TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.239.28.0/24 22080 0.8% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 2 - 85.239.24.0/24 21532 0.8% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 3 - 109.161.64.0/20 20451 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 4 - 89.221.206.0/24 17407 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 5 - 216.109.107.0/24 10207 0.4% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 6 - 85.249.160.0/20 9249 0.3% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 7 - 120.28.62.0/24 9188 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 222.127.0.0/24 8993 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 192.58.232.0/24 8895 0.3% AS6629 -- NOAA-AS - NOAA 10 - 205.247.12.0/24 7725 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 11 - 195.202.74.0/24 7587 0.3% AS9129 -- KE-NET2000 12 - 200.23.126.0/24 7039 0.3% AS8151 -- Uninet S.A. de C.V. 13 - 67.210.190.0/23 6969 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 14 - 206.152.15.0/24 6622 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 15 - 103.11.61.0/24 5280 0.2% AS9387 -- AUGERE-PK AUGERE-Pakistan 16 - 103.243.164.0/22 4975 0.2% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 17 - 67.210.188.0/23 4485 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 18 - 69.38.178.0/24 4072 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 19 - 199.187.118.0/24 3887 0.1% AS11054 -- LIVEPERSON LivePerson, Inc 20 - 66.214.67.0/24 2938 0.1% AS27505 -- DARK-PALADIN - Dark Paladin Productions Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From LarrySheldon at cox.net Fri Feb 14 23:00:27 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 14 Feb 2014 17:00:27 -0600 Subject: Permitting spoofed traffic [Was: Re: ddos attack blog] In-Reply-To: References: <52FD1359.4020909@flowtools.net> <20140214182229.GA34161@wakko.typo.org> Message-ID: <52FEA00B.5080508@cox.net> On 2/14/2014 12:42 PM, Paul Ferguson wrote: > Taken to the logical extreme, the "right thing" to do is to deny any > spoofed traffic from abusing these services altogether. Since the 1990s I have argued (ineffectively, it turns out) a case that says that sentence can be edited down to good advantage as: > Taken to the logical extreme, the "right thing" to do is to deny any > spoofed traffic. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From hmurray at megapathdsl.net Fri Feb 14 23:00:34 2014 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 14 Feb 2014 15:00:34 -0800 Subject: ddos attack blog Message-ID: <20140214230034.7F8AE406062@ip-64-139-1-69.sjc.megapath.net> > I was being a bit extreme, I don't expect UDP to be blocked and there are > valid uses for NTP and it needs to pass. Can you imagine the trading > servers not having access to NTP? Sure. They could setup internal NTP servers listening to GPS. Would it be as good overall as using external servers? Probably not, but it might be good enough. I doubt if it would be very high on any trading floors list of nasty problems. They could arrange to poke holes through the generic UDP block - whitelist the few known cases where UDP traffic is expected. Would it be a pain to administer? Probably, but I'll bet it could be made to work. -- These are my opinions. I hate spam. From joelja at bogus.com Fri Feb 14 23:19:42 2014 From: joelja at bogus.com (joel jaeggli) Date: Fri, 14 Feb 2014 15:19:42 -0800 Subject: ddos attack blog In-Reply-To: <20140214230034.7F8AE406062@ip-64-139-1-69.sjc.megapath.net> References: <20140214230034.7F8AE406062@ip-64-139-1-69.sjc.megapath.net> Message-ID: <52FEA48E.7010008@bogus.com> On 2/14/14, 3:00 PM, Hal Murray wrote: > >> I was being a bit extreme, I don't expect UDP to be blocked and there are >> valid uses for NTP and it needs to pass. Can you imagine the trading >> servers not having access to NTP? > > Sure. > > They could setup internal NTP servers listening to GPS. Would it be as good > overall as using external servers? Probably not, but it might be good > enough. I doubt if it would be very high on any trading floors list of nasty > problems. > > They could arrange to poke holes through the generic UDP block - whitelist > the few known cases where UDP traffic is expected. Would it be a pain to > administer? Probably, but I'll bet it could be made to work. High value concentrated applications are relatively easy things to get high quality time to. it's all the consumer electronics devices and everything that uses ssl/tls that needs access to time that is a more diffuse and less tractable problem. joel > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From nanog-post at rsuc.gweep.net Sat Feb 15 00:09:46 2014 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 14 Feb 2014 19:09:46 -0500 Subject: Permitting spoofed traffic [Was: Re: ddos attack blog] In-Reply-To: <52FE63AF.8010800@mykolab.com> References: <52FD1359.4020909@flowtools.net> <20140214182229.GA34161@wakko.typo.org> <52FE63AF.8010800@mykolab.com> Message-ID: <20140215000946.GA58005@gweep.net> On Fri, Feb 14, 2014 at 10:42:55AM -0800, Paul Ferguson wrote: [snip] > Taken to the logical extreme, the "right thing" to do is to deny any > spoofed traffic from abusing these services altogether. NTP is not the > only one; there is also SNMP, DNS, etc. ...and then we're back to "implement BCP38 already!" (like one of the authors of the document didn't think of that, ferg? ;-) NB: Some Entities believe all filtering is 'bcp 38' and thus have given this stone-dead logical and sane practice a bad rap. If someone is sloppy with their IRR-based filters or can't drive loose RPF correctly, that isn't the fault of BCP38. The document specifically speaks to aggregation points, most clearly in the introduction: "In other words, if an ISP is aggregating routing announcements for multiple downstream networks, strict traffic filtering should be used to prohibit traffic which claims to have originated from outside of these aggregated announcements." This goes for access, hosting, and most recently virtual hosting in teh cloude. Stop forgery at your edges and your life will be easier. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From fergdawgster at mykolab.com Sat Feb 15 02:05:11 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 14 Feb 2014 18:05:11 -0800 Subject: Permitting spoofed traffic [Was: Re: ddos attack blog] In-Reply-To: <52FEA00B.5080508@cox.net> References: <52FD1359.4020909@flowtools.net> <20140214182229.GA34161@wakko.typo.org> <52FEA00B.5080508@cox.net> Message-ID: <52FECB57.9050604@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/14/2014 3:00 PM, Larry Sheldon wrote: > On 2/14/2014 12:42 PM, Paul Ferguson wrote: >> Taken to the logical extreme, the "right thing" to do is to deny >> any spoofed traffic from abusing these services altogether. > > Since the 1990s I have argued (ineffectively, it turns out) a case > that says that sentence can be edited down to good advantage as: > >> Taken to the logical extreme, the "right thing" to do is to deny >> any spoofed traffic. > But of course. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL+y1QACgkQKJasdVTchbIgWgEAns/Nw6pqK+BaXSmI2DmP5J9Z mxeVg3KTCHdMBSDeZXAA/2+PlVSwHXdFem6hwRC/iv1+zscghkwUgimGbhKA5Gnx =VXx2 -----END PGP SIGNATURE----- From fergdawgster at mykolab.com Sat Feb 15 02:07:07 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 14 Feb 2014 18:07:07 -0800 Subject: Permitting spoofed traffic [Was: Re: ddos attack blog] In-Reply-To: <20140215000946.GA58005@gweep.net> References: <52FD1359.4020909@flowtools.net> <20140214182229.GA34161@wakko.typo.org> <52FE63AF.8010800@mykolab.com> <20140215000946.GA58005@gweep.net> Message-ID: <52FECBCB.3010405@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/14/2014 4:09 PM, Joe Provo wrote: > On Fri, Feb 14, 2014 at 10:42:55AM -0800, Paul Ferguson wrote: > [snip] >> Taken to the logical extreme, the "right thing" to do is to deny >> any spoofed traffic from abusing these services altogether. NTP >> is not the only one; there is also SNMP, DNS, etc. > > ...and then we're back to "implement BCP38 already!" (like one of > the authors of the document didn't think of that, ferg? ;-) > > NB: Some Entities believe all filtering is 'bcp 38' and thus have > given this stone-dead logical and sane practice a bad rap. If > someone is sloppy with their IRR-based filters or can't drive loose > RPF correctly, that isn't the fault of BCP38. > > The document specifically speaks to aggregation points, most > clearly in the introduction: "In other words, if an ISP is > aggregating routing announcements for multiple downstream networks, > strict traffic filtering should be used to prohibit traffic which > claims to have originated from outside of these aggregated > announcements." > > This goes for access, hosting, and most recently virtual hosting in > teh cloude. Stop forgery at your edges and your life will be > easier. > Indeed -- I'm not in the business of bit-shipping these days, so I can't endorse or advocate any particular method of blocking spoofed IP packets in your gear. I can, however, say with confidence that it is still a good idea. Great idea, even. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL+y8sACgkQKJasdVTchbKTXAEA0/czP0ECsFX4CyUr6yt4Dkap D0NZT/UIo6h5E/dl0KEA/3hpxN2NLxZRix6JUTVHyv+LZ4RzgpG2myoXbgAq1+WS =QQjA -----END PGP SIGNATURE----- From jeff-kell at utc.edu Sat Feb 15 02:18:17 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 14 Feb 2014 21:18:17 -0500 Subject: Permitting spoofed traffic [Was: Re: ddos attack blog] In-Reply-To: <52FECBCB.3010405@mykolab.com> References: <52FD1359.4020909@flowtools.net> <20140214182229.GA34161@wakko.typo.org> <52FE63AF.8010800@mykolab.com> <20140215000946 Message-ID: <52FECE69.9040009@utc.edu> On 2/14/2014 9:07 PM, Paul Ferguson wrote: > Indeed -- I'm not in the business of bit-shipping these days, so I > can't endorse or advocate any particular method of blocking spoofed IP > packets in your gear. If you're dead-end, a basic ACL that permits ONLY your prefixes on egress, and blocks your prefixes on ingress, is perhaps the safest bet. Strict uRPF has it's complications, and loose uRPF is almost too forgiving. If you're providing transit, it gets much more complicated much more quickly, but the same principles apply (they just get to be a less-than-100% solution) :) > I can, however, say with confidence that it is still a good idea. > Great idea, even. :-) Oh yeah :) Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From pashdown at xmission.com Sun Feb 16 18:29:17 2014 From: pashdown at xmission.com (Pete Ashdown) Date: Sun, 16 Feb 2014 11:29:17 -0700 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> Message-ID: <5301037D.7050401@xmission.com> Just in case you run a legitimate open NTP server, this iptable stanza helps immensely: ## rate limit ntp $IPTABLES -N NTP $IPTABLES -N BLACKHOLE $IPTABLES -A BLACKHOLE -m recent --set --name ntpv4blackhole --rsource $IPTABLES -A BLACKHOLE -j DROP $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 20 --name ntpv4 --rsource -j BLACKHOLE $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name ntpv4blackhole --rsource -j DROP $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP I've found that blocking TCP destination NTP to client servers/networks blocks legitimate NTP synchronization for their clients. Although I wish they'd all just use my on-network NTP server, I can't assume they will. Does anyone have a list or source of pool and vendor (Apple/Microsoft/etc) servers so I can permit based on source before blocking based on destination port? From pashdown at xmission.com Sun Feb 16 18:33:20 2014 From: pashdown at xmission.com (Pete Ashdown) Date: Sun, 16 Feb 2014 11:33:20 -0700 Subject: OpenNTPProject.org In-Reply-To: <5301037D.7050401@xmission.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> Message-ID: <53010470.80206@xmission.com> On 2/16/14, 11:29 AM, Pete Ashdown wrote: > I've found that blocking TCP destination NTP to client servers/networks > blocks legitimate NTP synchronization for their clients. ^TCP^UDP From blair.trosper at gmail.com Mon Feb 17 01:53:53 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Sun, 16 Feb 2014 19:53:53 -0600 Subject: Amazon network contact Message-ID: Could someone from Amazon Web Services contact me off list? You appear to be having connectivity problems on the private network (10.0.0.0/8) at US-EAST-1 between two or more zones, causing dozens of alarms and failures over the last 2-3 hours...however, there is no notation on the status page or any hint whatsoever of the problem. (The alarms are coming from the instance checks on the instances...which is the network...not the status checks...which would be the instance's health inside the PVM virtualization.) From brak at gameservers.com Mon Feb 17 02:38:06 2014 From: brak at gameservers.com (Brian Rak) Date: Sun, 16 Feb 2014 21:38:06 -0500 Subject: OpenNTPProject.org In-Reply-To: <5301037D.7050401@xmission.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> Message-ID: <5301760E.20009@gameservers.com> Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). $ ntpdc -c monlist -n clock.xmission.com remote address port local address count m ver code avgint lstint =============================================================================== 173.209.207.233 42422 198.60.22.240 4727 3 3 0 0 0 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 107.0.41.2 48625 198.60.22.240 264 3 4 0 5 0 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 103.7.36.38 51618 198.60.22.240 4 3 3 0 8 0 173.209.207.218 50616 198.60.22.240 4731 3 3 0 0 0 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 75.82.183.104 123 198.60.22.240 1 3 4 0 0 0 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 65.201.33.150 151 198.60.22.240 393 3 2 0 3 0 124.228.119.105 24687 198.60.22.240 31 3 3 0 4 0 64.191.150.130 319 198.60.22.240 4494361 3 2 0 0 0 76.102.124.27 123 198.60.22.240 2 3 4 0 0 0 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 63.64.124.144 26984 198.60.22.240 5823740 3 4 0 0 0 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 143.112.64.2 1320 198.60.22.240 182 1 3 0 6 0 72.235.19.125 123 198.60.22.240 1 3 4 0 0 0 198.237.66.2 10471 198.60.22.240 499 3 3 0 3 0 12.108.21.226 357 198.60.22.240 10 1 3 0 14 0 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 67.136.57.10 1026 198.60.22.240 243 3 3 0 5 0 64.199.163.5 306 198.60.22.240 231 3 4 0 4 0 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. On 2/16/2014 1:29 PM, Pete Ashdown wrote: > Just in case you run a legitimate open NTP server, this iptable stanza > helps immensely: > > ## rate limit ntp > $IPTABLES -N NTP > $IPTABLES -N BLACKHOLE > $IPTABLES -A BLACKHOLE -m recent --set --name ntpv4blackhole --rsource > $IPTABLES -A BLACKHOLE -j DROP > $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 20 --name > ntpv4 --rsource -j BLACKHOLE > $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name > ntpv4blackhole --rsource -j DROP > $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT > $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP > > > I've found that blocking TCP destination NTP to client servers/networks > blocks legitimate NTP synchronization for their clients. Although I > wish they'd all just use my on-network NTP server, I can't assume they > will. Does anyone have a list or source of pool and vendor > (Apple/Microsoft/etc) servers so I can permit based on source before > blocking based on destination port? > > From kate at quadranet.com Mon Feb 17 03:03:59 2014 From: kate at quadranet.com (Kate Gerry) Date: Sun, 16 Feb 2014 19:03:59 -0800 Subject: OpenNTPProject.org In-Reply-To: <5301760E.20009@gameservers.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> Just add these to your ntp.conf configuration then restart the service: (Works with all default installations that I've found) restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery -- Kate Gerry Network Manager kate at quadranet.com 1-888-5-QUADRA Ext 206?|?www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: ? -----Original Message----- From: Brian Rak [mailto:brak at gameservers.com] Sent: Sunday, February 16, 2014 6:38 PM To: Pete Ashdown; NANOG list Subject: Re: OpenNTPProject.org Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). $ ntpdc -c monlist -n clock.xmission.com remote address port local address count m ver code avgint lstint =============================================================================== 173.209.207.233 42422 198.60.22.240 4727 3 3 0 0 0 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 107.0.41.2 48625 198.60.22.240 264 3 4 0 5 0 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 103.7.36.38 51618 198.60.22.240 4 3 3 0 8 0 173.209.207.218 50616 198.60.22.240 4731 3 3 0 0 0 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 75.82.183.104 123 198.60.22.240 1 3 4 0 0 0 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 65.201.33.150 151 198.60.22.240 393 3 2 0 3 0 124.228.119.105 24687 198.60.22.240 31 3 3 0 4 0 64.191.150.130 319 198.60.22.240 4494361 3 2 0 0 0 76.102.124.27 123 198.60.22.240 2 3 4 0 0 0 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 63.64.124.144 26984 198.60.22.240 5823740 3 4 0 0 0 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 143.112.64.2 1320 198.60.22.240 182 1 3 0 6 0 72.235.19.125 123 198.60.22.240 1 3 4 0 0 0 198.237.66.2 10471 198.60.22.240 499 3 3 0 3 0 12.108.21.226 357 198.60.22.240 10 1 3 0 14 0 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 67.136.57.10 1026 198.60.22.240 243 3 3 0 5 0 64.199.163.5 306 198.60.22.240 231 3 4 0 4 0 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. On 2/16/2014 1:29 PM, Pete Ashdown wrote: > Just in case you run a legitimate open NTP server, this iptable stanza > helps immensely: > > ## rate limit ntp > $IPTABLES -N NTP > $IPTABLES -N BLACKHOLE > $IPTABLES -A BLACKHOLE -m recent --set --name ntpv4blackhole --rsource > $IPTABLES -A BLACKHOLE -j DROP > $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 20 --name > ntpv4 --rsource -j BLACKHOLE > $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name > ntpv4blackhole --rsource -j DROP > $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT > $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP > > > I've found that blocking TCP destination NTP to client servers/networks > blocks legitimate NTP synchronization for their clients. Although I > wish they'd all just use my on-network NTP server, I can't assume they > will. Does anyone have a list or source of pool and vendor > (Apple/Microsoft/etc) servers so I can permit based on source before > blocking based on destination port? > > From mark.tinka at seacom.mu Mon Feb 17 03:59:43 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 17 Feb 2014 05:59:43 +0200 Subject: OpenNTPProject.org In-Reply-To: <5301760E.20009@gameservers.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> Message-ID: <201402170559.43562.mark.tinka@seacom.mu> On Monday, February 17, 2014 04:38:06 AM Brian Rak wrote: > There is no excuse to still be running a NTP server with > monlist enabled. Fix your configuration, and you don't > need IPTables rules. Juniper's Junos implementation (which is based on FreeBSD) hasn't been patched Using firewall filters is the only way to mitigate the vulnerability. For those with Juniper access: http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613&actp=SUBSCRIPTION It's not clear when the software patch will be made available. As it were, ScreenOS and JUNOSe are not affected, as they don't support the MONLIST feature. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From james.cutler at consultant.com Mon Feb 17 04:04:34 2014 From: james.cutler at consultant.com (James R Cutler) Date: Sun, 16 Feb 2014 23:04:34 -0500 Subject: OpenNTPProject.org In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> Message-ID: On Feb 16, 2014, at 10:03 PM, Kate Gerry wrote: > Just add these to your ntp.conf configuration then restart the service: (Works with all default installations that I've found) > > restrict default kod nomodify notrap nopeer noquery > restrict -6 default kod nomodify notrap nopeer noquery It might be useful to note that OS X has long since included these lines in the default NTP daemon configuration (/etc/ntp-restrict.conf) thus, ?No worrys, mate." James R. Cutler - james.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lyndon at orthanc.ca Mon Feb 17 04:09:01 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 16 Feb 2014 20:09:01 -0800 Subject: OpenNTPProject.org In-Reply-To: <201402170559.43562.mark.tinka@seacom.mu> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <201402170559.43562.mark.tinka@seacom.mu> Message-ID: <1BF56ACA-672D-4281-8430-291970A6D61E@orthanc.ca> On Feb 16, 2014, at 7:59 PM, Mark Tinka wrote: > Juniper's Junos implementation (which is based on FreeBSD) > hasn't been patched > > Using firewall filters is the only way to mitigate the > vulnerability. But doesn't the JunOS ntpd read/parse ntpd.conf? It's worth getting to the admin mode shell prompt and taking a poke around /etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From morrowc.lists at gmail.com Mon Feb 17 04:30:09 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 16 Feb 2014 23:30:09 -0500 Subject: OpenNTPProject.org In-Reply-To: <1BF56ACA-672D-4281-8430-291970A6D61E@orthanc.ca> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <201402170559.43562.mark.tinka@seacom.mu> <1BF56ACA-672D-4281-8430-291970A6D61E@orthanc.ca> Message-ID: On Sun, Feb 16, 2014 at 11:09 PM, Lyndon Nerenberg wrote: > > On Feb 16, 2014, at 7:59 PM, Mark Tinka wrote: > >> Juniper's Junos implementation (which is based on FreeBSD) >> hasn't been patched >> >> Using firewall filters is the only way to mitigate the >> vulnerability. > > But doesn't the JunOS ntpd read/parse ntpd.conf? It's worth getting to the admin mode shell prompt and taking a poke around /etc. and good luck with figuring out: 1) when you need to re-do that magic move 2) making sure that the move is automatable over time it's sort of weird that the service on a routing platform supports more than 'the current time is XX:YY::ZZ' anyway, eh? From lyndon at orthanc.ca Mon Feb 17 04:35:46 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 16 Feb 2014 20:35:46 -0800 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <201402170559.43562.mark.tinka@seacom.mu> <1BF56ACA-672D-4281-8430-291970A6D61E@orthanc.ca> Message-ID: On Feb 16, 2014, at 8:30 PM, Christopher Morrow wrote: > and good luck with figuring out: > 1) when you need to re-do that magic move > 2) making sure that the move is automatable over time I was suggesting it as an alternative to just chopping off NTP at your border. Presumably it would be a one-off thing until Juniper issues a patch. As for automating it, 'expect' can be a very useful tool in situations like this. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mark.tinka at seacom.mu Mon Feb 17 04:37:42 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 17 Feb 2014 06:37:42 +0200 Subject: OpenNTPProject.org In-Reply-To: <1BF56ACA-672D-4281-8430-291970A6D61E@orthanc.ca> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <201402170559.43562.mark.tinka@seacom.mu> <1BF56ACA-672D-4281-8430-291970A6D61E@orthanc.ca> Message-ID: <201402170637.46609.mark.tinka@seacom.mu> On Monday, February 17, 2014 06:09:01 AM Lyndon Nerenberg wrote: > But doesn't the JunOS ntpd read/parse ntpd.conf? It's > worth getting to the admin mode shell prompt and taking > a poke around /etc. You can get access to the shell and edit the daemon configuration files yourself, but based on similar tactics for other areas of Junos (including things like Cron) that some operators have done, it is with reasonable reliability that any custom changes will not persist through software upgrades. So either you add this to the to-do list each time you upgrade code, or get Juniper to fix it natively (since it is now fixed in FreeBSD). In fairness, I haven't tried to muck about with the Junos FreeBSD shell to do this, partly for the reasons above, mostly because my life is already interesting enough :-). If someone else has and can provide a different perspective, please do. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Mon Feb 17 04:42:15 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 17 Feb 2014 06:42:15 +0200 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> Message-ID: <201402170642.15458.mark.tinka@seacom.mu> On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg wrote: > I was suggesting it as an alternative to just chopping > off NTP at your border. Presumably it would be a > one-off thing until Juniper issues a patch. In Junos, applying the right filters to your router's control plane will fix the issue. You don't need to block NTP in the data plane. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From morrowc.lists at gmail.com Mon Feb 17 06:31:01 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 17 Feb 2014 01:31:01 -0500 Subject: OpenNTPProject.org In-Reply-To: <201402170642.15458.mark.tinka@seacom.mu> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <201402170642.15458.mark.tinka@seacom.mu> Message-ID: On Sun, Feb 16, 2014 at 11:42 PM, Mark Tinka wrote: > On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg > wrote: > >> I was suggesting it as an alternative to just chopping >> off NTP at your border. Presumably it would be a >> one-off thing until Juniper issues a patch. > > In Junos, applying the right filters to your router's > control plane will fix the issue. You don't need to block > NTP in the data plane. yes, this. From pashdown at xmission.com Mon Feb 17 07:23:43 2014 From: pashdown at xmission.com (Pete Ashdown) Date: Mon, 17 Feb 2014 00:23:43 -0700 Subject: OpenNTPProject.org In-Reply-To: <5301760E.20009@gameservers.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> Message-ID: <5301B8FF.3050502@xmission.com> On 2/16/14, 7:38 PM, Brian Rak wrote: > Seriously, just fix your configuration. The part of NTP being abused > is completely unrelated to actually synchronizing time. It's a > management query, that has no real reason to be enabled remotely. You > don't even need to resort to iptables for this, because NTPD has built > in rate limiting (which isn't enabled for management queries, but > those are trivial to disable). Thanks for the tip, monitoring is off. I was under the impression that rate-limiting hadn't made it into a stable version of ntpd yet. Is that incorrect? From brak at gameservers.com Mon Feb 17 13:45:32 2014 From: brak at gameservers.com (Brian Rak) Date: Mon, 17 Feb 2014 08:45:32 -0500 Subject: OpenNTPProject.org In-Reply-To: <5301B8FF.3050502@xmission.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <5301B8FF.3050502@xmission.com> Message-ID: <5302127C.1060204@gameservers.com> Rate limitings been in place for quite some time, but I believe it's only for actual time queries. This DDOS uses monlist, which isn't subject to the same rate limits. You've disabled monlist now, so I bet you'll no longer need all the rate limiting IPTables rules. (Though, you'll still see the incoming garbage for awhile, but NTPD will just discard it so it shouldn't cause problems). On 2/17/2014 2:23 AM, Pete Ashdown wrote: > On 2/16/14, 7:38 PM, Brian Rak wrote: >> Seriously, just fix your configuration. The part of NTP being abused >> is completely unrelated to actually synchronizing time. It's a >> management query, that has no real reason to be enabled remotely. You >> don't even need to resort to iptables for this, because NTPD has built >> in rate limiting (which isn't enabled for management queries, but >> those are trivial to disable). > Thanks for the tip, monitoring is off. I was under the impression that > rate-limiting hadn't made it into a stable version of ntpd yet. Is that > incorrect? > > From wesley.george at twcable.com Mon Feb 17 14:26:42 2014 From: wesley.george at twcable.com (George, Wes) Date: Mon, 17 Feb 2014 09:26:42 -0500 Subject: OpenNTPProject.org In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> Message-ID: I?ll note that this is less than 140 chars, and therefore fits nicely in a tweet. If you?re on twitter, Signal boost the PSA, please. My edited example: https://twitter.com/wesgeorge/status/435404354242478080 Wes George On 2/16/14, 10:03 PM, "Kate Gerry" wrote: >add these to your ntp.conf >restrict default kod nomodify notrap nopeer noquery >restrict -6 default kod nomodify notrap nopeer noquery Anything below this line has been added by my company?s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From contact at winterei.se Mon Feb 17 03:34:40 2014 From: contact at winterei.se (Paul S.) Date: Mon, 17 Feb 2014 09:34:40 +0600 Subject: OpenNTPProject.org In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> Message-ID: <53018350.8010707@winterei.se> Better yet, why is your ntp server even reachable off net? Providing a public clock service needs a lot more configuration effort than a simple, default one -- as just demonstrated. (However, this is not to say that private servers should have management queries enabled.) On 2/17/2014 9:03 AM, Kate Gerry wrote: > Just add these to your ntp.conf configuration then restart the service: (Works with all default installations that I've found) > > restrict default kod nomodify notrap nopeer noquery > restrict -6 default kod nomodify notrap nopeer noquery > > -- > Kate Gerry > Network Manager > kate at quadranet.com > > 1-888-5-QUADRA Ext 206 | www.QuadraNet.com > Dedicated Servers, Colocation, Cloud Services and more. > Datacenters in Los Angeles, Dallas and Miami. > > Follow us on: > > > -----Original Message----- > From: Brian Rak [mailto:brak at gameservers.com] > Sent: Sunday, February 16, 2014 6:38 PM > To: Pete Ashdown; NANOG list > Subject: Re: OpenNTPProject.org > > Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). > > $ ntpdc -c monlist -n clock.xmission.com > remote address port local address count m ver code avgint > lstint > =============================================================================== > 173.209.207.233 42422 198.60.22.240 4727 3 3 0 0 0 > 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 > 107.0.41.2 48625 198.60.22.240 264 3 4 0 5 0 > 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 > 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 > 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 > 103.7.36.38 51618 198.60.22.240 4 3 3 0 8 0 > 173.209.207.218 50616 198.60.22.240 4731 3 3 0 0 0 > 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 > 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 > 75.82.183.104 123 198.60.22.240 1 3 4 0 0 0 > 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 > 65.201.33.150 151 198.60.22.240 393 3 2 0 3 0 > 124.228.119.105 24687 198.60.22.240 31 3 3 0 4 0 > 64.191.150.130 319 198.60.22.240 4494361 3 2 0 0 0 > 76.102.124.27 123 198.60.22.240 2 3 4 0 0 0 > 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 > 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 > 63.64.124.144 26984 198.60.22.240 5823740 3 4 0 0 0 > 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 > 143.112.64.2 1320 198.60.22.240 182 1 3 0 6 0 > 72.235.19.125 123 198.60.22.240 1 3 4 0 0 0 > 198.237.66.2 10471 198.60.22.240 499 3 3 0 3 0 > 12.108.21.226 357 198.60.22.240 10 1 3 0 14 0 > 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 > 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 > 67.136.57.10 1026 198.60.22.240 243 3 3 0 5 0 > 64.199.163.5 306 198.60.22.240 231 3 4 0 4 0 > 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 > > There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. > > > > On 2/16/2014 1:29 PM, Pete Ashdown wrote: >> Just in case you run a legitimate open NTP server, this iptable stanza >> helps immensely: >> >> ## rate limit ntp >> $IPTABLES -N NTP >> $IPTABLES -N BLACKHOLE >> $IPTABLES -A BLACKHOLE -m recent --set --name ntpv4blackhole --rsource >> $IPTABLES -A BLACKHOLE -j DROP >> $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 20 --name >> ntpv4 --rsource -j BLACKHOLE >> $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name >> ntpv4blackhole --rsource -j DROP >> $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT >> $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP >> >> >> I've found that blocking TCP destination NTP to client servers/networks >> blocks legitimate NTP synchronization for their clients. Although I >> wish they'd all just use my on-network NTP server, I can't assume they >> will. Does anyone have a list or source of pool and vendor >> (Apple/Microsoft/etc) servers so I can permit based on source before >> blocking based on destination port? >> >> > > From stenn at ntp.org Mon Feb 17 04:07:53 2014 From: stenn at ntp.org (Harlan Stenn) Date: Mon, 17 Feb 2014 04:07:53 +0000 Subject: OpenNTPProject.org In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> Message-ID: Kate Gerry writes: > Just add these to your ntp.conf configuration then restart the service: (Wo= > rks with all default installations that I've found) > > restrict default kod nomodify notrap nopeer noquery > restrict -6 default kod nomodify notrap nopeer noquery KOD only works with "limited" in the release of NTP you are using. H From stenn at ntp.org Mon Feb 17 04:24:33 2014 From: stenn at ntp.org (Harlan Stenn) Date: Mon, 17 Feb 2014 04:24:33 +0000 Subject: OpenNTPProject.org In-Reply-To: <201402170559.43562.mark.tinka@seacom.mu> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <201402170559.43562.mark.tinka@seacom.mu> Message-ID: If somebody has contacts at Juniper who is involved in this, I'd like to get their contact information. -- Harlan Stenn http://networktimefoundation.org - be a member! From sunyucong at gmail.com Mon Feb 17 05:26:10 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Sun, 16 Feb 2014 21:26:10 -0800 Subject: OpenNTPProject.org In-Reply-To: <201402170642.15458.mark.tinka@seacom.mu> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <201402170642.15458.mark.tinka@seacom.mu> Message-ID: Just for the reference, here is a more complete solution for Junos (took me a while searching the web to figure it out), hope it helps someone. policy-options { prefix-list lo0.0-inet-address { apply-path "interfaces lo0 unit 0 family inet address <*>"; } prefix-list ntp-servers { apply-path "system ntp server <*>"; } } firewall { family inet { filter lo-filter { term ntp-allow { from { source-prefix-list { ntp-servers; lo0.0-inet-address; } protocol udp; destination-port ntp; } then accept; } term ntp-other-discard { from { protocol udp; destination-port ntp; } then { discard; } } term zz-accept { then accept; } } } } On Sun, Feb 16, 2014 at 8:42 PM, Mark Tinka wrote: > On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg > wrote: > > > I was suggesting it as an alternative to just chopping > > off NTP at your border. Presumably it would be a > > one-off thing until Juniper issues a patch. > > In Junos, applying the right filters to your router's > control plane will fix the issue. You don't need to block > NTP in the data plane. > > Mark. > From pashdown at xmission.com Mon Feb 17 15:14:44 2014 From: pashdown at xmission.com (Pete Ashdown) Date: Mon, 17 Feb 2014 08:14:44 -0700 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> Message-ID: <53022764.8080709@xmission.com> On 2/17/14, 7:26 AM, George, Wes wrote: > I?ll note that this is less than 140 chars, and therefore fits nicely in a > tweet. > > If you?re on twitter, Signal boost the PSA, please. > > My edited example: https://twitter.com/wesgeorge/status/435404354242478080 > > Wes George > > > > On 2/16/14, 10:03 PM, "Kate Gerry" wrote: > >> add these to your ntp.conf >> restrict default kod nomodify notrap nopeer noquery >> restrict -6 default kod nomodify notrap nopeer noquery I seem to recall some issue with older Windows clients using peer for synchronization. Does not having "nopeer" contribute to DDoS amplification? From ikiris at gmail.com Mon Feb 17 15:28:16 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 17 Feb 2014 09:28:16 -0600 Subject: OpenNTPProject.org In-Reply-To: <53022764.8080709@xmission.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> <53022764.8080709@xmission.com> Message-ID: Peer means it considers the other side an equal and they will mutually skew time together. If you have peer on for devices you don't consider your time servers, you're opening yourself up to problems. -Blake On Mon, Feb 17, 2014 at 9:14 AM, Pete Ashdown wrote: > On 2/17/14, 7:26 AM, George, Wes wrote: > > I'll note that this is less than 140 chars, and therefore fits nicely in > a > > tweet. > > > > If you're on twitter, Signal boost the PSA, please. > > > > My edited example: > https://twitter.com/wesgeorge/status/435404354242478080 > > > > Wes George > > > > > > > > On 2/16/14, 10:03 PM, "Kate Gerry" wrote: > > > >> add these to your ntp.conf > >> restrict default kod nomodify notrap nopeer noquery > >> restrict -6 default kod nomodify notrap nopeer noquery > > I seem to recall some issue with older Windows clients using peer for > synchronization. Does not having "nopeer" contribute to DDoS > amplification? > > > From rdobbins at arbor.net Mon Feb 17 15:32:48 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 17 Feb 2014 15:32:48 +0000 Subject: OpenNTPProject.org In-Reply-To: <53022764.8080709@xmission.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> <53022764.8080709@xmission.com> Message-ID: On Feb 17, 2014, at 10:14 PM, Pete Ashdown wrote: > Does not having "nopeer" contribute to DDoS amplification? No: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From alby.williams at verizon.com Mon Feb 17 15:38:30 2014 From: alby.williams at verizon.com (Anthony Williams) Date: Mon, 17 Feb 2014 10:38:30 -0500 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> <53022764.8080709@xmission.com> Message-ID: <53022CF6.3010208@one.verizon.com> Blake: Just to make sure I've got this down, listing a device as a "peer" in the ntp.conf file will create a situation where both devices are saying, "I know what time it is" and splitting the difference? Whereas when you list a device as a "server", it's using that as the authority on the correct time? Example: -- # peer 192.168.1.1 iburst peer 192.168.1.2 iburst # server ntp.colby.edu minpoll 6 maxpoll 10 iburst server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst On 2/17/2014 10:28 AM, Blake Dunlap wrote: > Peer means it considers the other side an equal and they will mutually skew > time together. If you have peer on for devices you don't consider your time > servers, you're opening yourself up to problems. > > -Blake From jra at baylink.com Mon Feb 17 15:54:38 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 17 Feb 2014 10:54:38 -0500 (EST) Subject: Monday BCP38.info reminder In-Reply-To: <11673743.8548.1392652226316.JavaMail.root@benjamin.baylink.com> Message-ID: <11413420.8550.1392652478367.JavaMail.root@benjamin.baylink.com> Standard[1] Monday[2] Reminder[3]: DDOS attacks are bad. DDOS attacks that you can't tell where they're coming from are worse. BCP38 helps eliminate the latter, which helps markedly with the former. BCP38 is usually relatively easy to implement. Most of you people know how to do it already, and we'd really like your help in teaching the rest. http://www.bcp38.info If you know something, write something[4]. Cheers, -- jra [1] Until we move 75% up to like 95%, at least. [2] Unless I forget. [3] And apparently we need one; 3 Really Smart Guys *including Ferg* posted on BCP38 this morning, and none promoted the page. [4] Slogan stolen from a much stupider Security Theatre And Paranoia slogan -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From james.cutler at consultant.com Mon Feb 17 16:01:41 2014 From: james.cutler at consultant.com (James R Cutler) Date: Mon, 17 Feb 2014 11:01:41 -0500 Subject: OpenNTPProject.org In-Reply-To: <53022CF6.3010208@one.verizon.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> <53022764.8080709@xmission.com> <53022CF6.3010208@one.verizon.com> Message-ID: <2152B4D5-8733-4E19-A750-9DD6B2245229@consultant.com> On Feb 17, 2014, at 10:38 AM, Anthony Williams wrote: > Blake: > > Just to make sure I've got this down, listing a device as a "peer" in > the ntp.conf file will create a situation where both devices are saying, > "I know what time it is" and splitting the difference? Whereas when you > list a device as a "server", it's using that as the authority on the > correct time? That is not exactly correct. Listing a system as peer or server means that the time from that system will be used as input to the synchronization algorithm. The selection process may discard data depending on various criteria regardless of peer/server designation. The operations implications are the requirement for your own robust group of peers > 3 and lots of servers. See ? RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification ? RFC 5906: Network Time Protocol Version 4: Autokey Specification ? RFC 5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) ? RFC 5908: Network Time Protocol (NTP) Server Option for DHCPv6 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ikiris at gmail.com Mon Feb 17 16:02:35 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 17 Feb 2014 10:02:35 -0600 Subject: OpenNTPProject.org In-Reply-To: <53022CF6.3010208@one.verizon.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> <53022764.8080709@xmission.com> <53022CF6.3010208@one.verizon.com> Message-ID: If you're trying to actually run a ntp server setup as opposed to just trusting the world, I strongly suggest reading the documentation for the service, as most people don't deploy it correctly while they think they have. At minimum, you want a cluster of 3 - 4 servers internally, configured as peers of each other, and listening to some source of time, preferably multiple like a few on the internet from the big public pool, and if you really care about time, set up a GPS receiver or two. You can definitely go farther than the above, but that's the start to doing it right. Anything short of the above is just trusting the world at large, and you'll likely happily follow along with any time skew like that thing a few months/year ago with either tick or tock. Without the above, you don't have enough sane sources to discredit bad advisers (you need 3 for a time lock). -Blake On Mon, Feb 17, 2014 at 9:38 AM, Anthony Williams wrote: > > Blake: > > Just to make sure I've got this down, listing a device as a "peer" in > the ntp.conf file will create a situation where both devices are saying, > "I know what time it is" and splitting the difference? Whereas when you > list a device as a "server", it's using that as the authority on the > correct time? > > Example: > -- > > # > peer 192.168.1.1 iburst > peer 192.168.1.2 iburst > > > # > server ntp.colby.edu minpoll 6 maxpoll 10 iburst > server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst > > > > > > On 2/17/2014 10:28 AM, Blake Dunlap wrote: > > Peer means it considers the other side an equal and they will mutually > skew > > time together. If you have peer on for devices you don't consider your > time > > servers, you're opening yourself up to problems. > > > > -Blake > > > From betty at newnog.org Mon Feb 17 23:56:05 2014 From: betty at newnog.org (Betty Burke ) Date: Mon, 17 Feb 2014 18:56:05 -0500 Subject: [NANOG-announce] ARIN+NANOG on the Road San Diego reminder Message-ID: Colleagues: A reminder note for those who are, or know of someone local, to San Diego; do not delay, ARIN+NANOG on the Roadis fast approaching. We have a great program planned for the Tuesday, February 28, 2014 at the Handerly Hotel. There is no fee to attend, however registration for the event is requested. We are expecting strong attendance and hope to see many NANOGers next week. Be sure to add your name and registertoday. All best. Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From muhammad.adnan200 at gmail.com Mon Feb 17 15:27:25 2014 From: muhammad.adnan200 at gmail.com (Muhammad Adnan) Date: Mon, 17 Feb 2014 15:27:25 +0000 Subject: Work Practices of Cyber Security Professionals Message-ID: Dear Sir/Madam, I am a university researcher who is investigating the development of new, usable tools that will improve the work practices of cyber security professionals. As a first step to achieve this goal, I am undertaking a survey to gain an in-depth understanding of the day-to-day activities of cyber security professionals. The targeted participants for this survey are those who perform security related activities as a part of their job (e.g. security analysts, network administrators, penetration testers). I would be very grateful if you could spare some time and complete this short (10 minutes) survey for me. It can be accessed at the following link: http://edu.surveygizmo.com/s3/1536165/Work-Practices-of-Cyber-Security-Professionals If you have questions or concerns about this research, please contact me ( Muhammad.Adnan at gcu.ac.uk) or my Ph.D. supervisor Dr. Mike Just ( Mike.Just at gcu.ac.uk), both at the Interactive and Trustworthy Technologies research group (http://www.ittgroup.org/), Glasgow Caledonian University, UK. Kind regards, Adnan From jared at puck.nether.net Tue Feb 18 14:14:59 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Feb 2014 09:14:59 -0500 Subject: JunOS NTP - Re: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <201402170642.15458.mark.tinka@seacom.mu> Message-ID: <54FEF003-18F0-4604-A2E3-D54819DCABA8@puck.nether.net> So, be careful as the Juniper solution varies depending on the platform involved. Make sure you check your devices. It took a few iterations for us to get the right filters on everything. - Jared On Feb 17, 2014, at 12:26 AM, Yucong Sun wrote: > Just for the reference, here is a more complete solution for Junos (took me > a while searching the web to figure it out), hope it helps someone. > > policy-options { > prefix-list lo0.0-inet-address { > apply-path "interfaces lo0 unit 0 family inet address <*>"; > } > prefix-list ntp-servers { > apply-path "system ntp server <*>"; > } > } > > firewall { > family inet { > filter lo-filter { > term ntp-allow { > from { > source-prefix-list { > ntp-servers; > lo0.0-inet-address; > } > protocol udp; > destination-port ntp; > } > then accept; > } > term ntp-other-discard { > from { > protocol udp; > destination-port ntp; > } > then { > discard; > } > } > term zz-accept { > then accept; > } > } > } > } > > > > On Sun, Feb 16, 2014 at 8:42 PM, Mark Tinka wrote: > >> On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg >> wrote: >> >>> I was suggesting it as an alternative to just chopping >>> off NTP at your border. Presumably it would be a >>> one-off thing until Juniper issues a patch. >> >> In Junos, applying the right filters to your router's >> control plane will fix the issue. You don't need to block >> NTP in the data plane. >> >> Mark. >> From Valdis.Kletnieks at vt.edu Tue Feb 18 14:28:55 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 18 Feb 2014 09:28:55 -0500 Subject: Work Practices of Cyber Security Professionals In-Reply-To: Your message of "Mon, 17 Feb 2014 15:27:25 +0000." References: Message-ID: <256716.1392733735@turing-police.cc.vt.edu> On Mon, 17 Feb 2014 15:27:25 +0000, Muhammad Adnan said: > I am a university researcher who is investigating the development of new, > usable tools that will improve the work practices of cyber security > professionals. As a first step to achieve this goal, I am undertaking a > survey to gain an in-depth understanding of the day-to-day activities of > cyber security professionals. The targeted participants for this survey are > those who perform security related activities as a part of their job (e.g. > security analysts, network administrators, penetration testers). Several comments: 1) If you're including network admins, you should also make sure to get system admins (though you'll be more successful asking elsewhere for those). 2) Having worn at least a partial hat of all those along my careeer, I'm curious what sort of tools will improve work practices for all the groups concerned. Probably the only place you'll find much overlap is in record keeping - but even there the record keeping that a sysadmin needs to do for changelogging their boxes is fairly different from what security analysts working an incident and pen testers engaged in a test will need. There's also the problem that many sites have their change logging integrated into their version control system or other workflow software already... Good luck! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mwalter at 3z.net Tue Feb 18 15:15:47 2014 From: mwalter at 3z.net (Mike Walter) Date: Tue, 18 Feb 2014 15:15:47 +0000 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <5301037D.7050401@xmission.com> <5301760E.20009@gameservers.com> <4B4120B1642DCF48ACA84E4F82C8E1F60103B7A00FC7@EXCH> <53022764.8080709@xmission.com> <53022CF6.3010208@one.verizon.com> Message-ID: For knowledge on the list. We found that our Cisco Nexus 7000s had NTP enabled on our public facing VDCs, even when the command "feature ntp" was not present. I had to explicitly enter "no feature ntp" to prevent the NTP server service from existing on our public facing 7K interfaces. Thanks, Mike -----Original Message----- From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Monday, February 17, 2014 11:03 AM To: nanog at nanog.org Subject: Re: OpenNTPProject.org If you're trying to actually run a ntp server setup as opposed to just trusting the world, I strongly suggest reading the documentation for the service, as most people don't deploy it correctly while they think they have. At minimum, you want a cluster of 3 - 4 servers internally, configured as peers of each other, and listening to some source of time, preferably multiple like a few on the internet from the big public pool, and if you really care about time, set up a GPS receiver or two. You can definitely go farther than the above, but that's the start to doing it right. Anything short of the above is just trusting the world at large, and you'll likely happily follow along with any time skew like that thing a few months/year ago with either tick or tock. Without the above, you don't have enough sane sources to discredit bad advisers (you need 3 for a time lock). -Blake On Mon, Feb 17, 2014 at 9:38 AM, Anthony Williams wrote: > > Blake: > > Just to make sure I've got this down, listing a device as a "peer" in > the ntp.conf file will create a situation where both devices are saying, > "I know what time it is" and splitting the difference? Whereas when you > list a device as a "server", it's using that as the authority on the > correct time? > > Example: > -- > > # > peer 192.168.1.1 iburst > peer 192.168.1.2 iburst > > > # > server ntp.colby.edu minpoll 6 maxpoll 10 iburst > server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst > > > > > > On 2/17/2014 10:28 AM, Blake Dunlap wrote: > > Peer means it considers the other side an equal and they will mutually > skew > > time together. If you have peer on for devices you don't consider your > time > > servers, you're opening yourself up to problems. > > > > -Blake > > > From jay at prolexic.com Tue Feb 18 15:25:24 2014 From: jay at prolexic.com (Jay Coley) Date: Tue, 18 Feb 2014 10:25:24 -0500 Subject: Telia contact Message-ID: <53037B64.50803@prolexic.com> Hi, If there are any Telia engineers lurking about could you please contact me off-list regarding a routing question? Thanks! --J From jay at prolexic.com Tue Feb 18 15:25:31 2014 From: jay at prolexic.com (Jay Coley) Date: Tue, 18 Feb 2014 10:25:31 -0500 Subject: Telia contact Message-ID: <53037B6B.5010709@prolexic.com> Hi, If there are any Telia engineers lurking about could you please contact me off-list regarding a routing question? Thanks! --J From jtk at cymru.com Tue Feb 18 15:55:25 2014 From: jtk at cymru.com (John Kristoff) Date: Tue, 18 Feb 2014 09:55:25 -0600 Subject: JunOS NTP - Re: OpenNTPProject.org In-Reply-To: <54FEF003-18F0-4604-A2E3-D54819DCABA8@puck.nether.net> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <201402170642.15458.mark.tinka@seacom.mu> <54FEF003-18F0-4604-A2E3-D54819DCABA8@puck.nether.net> Message-ID: <20140218095525.6a3e7707@localhost> On Tue, 18 Feb 2014 09:14:59 -0500 Jared Mauch wrote: > > prefix-list ntp-servers { > > apply-path "system ntp server <*>"; Some people also have a 'boot-server [server]' statement. In the off chance that address is different than those listed in the server statements, you may need to account for it as well. If you can, just make sure it is also listed as one of the configured servers. John From mark.tinka at seacom.mu Tue Feb 18 16:33:48 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 18 Feb 2014 18:33:48 +0200 Subject: JunOS NTP - Re: OpenNTPProject.org In-Reply-To: <54FEF003-18F0-4604-A2E3-D54819DCABA8@puck.nether.net> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <54FEF003-18F0-4604-A2E3-D54819DCABA8@puck.nether.net> Message-ID: <201402181833.51772.mark.tinka@seacom.mu> On Tuesday, February 18, 2014 04:14:59 PM Jared Mauch wrote: > So, be careful as the Juniper solution varies depending > on the platform involved. > > Make sure you check your devices. It took a few > iterations for us to get the right filters on > everything. Indeed. In particular, different hardware and software combinations for the EX line have different match conditions for ports compared to the routers. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jra at baylink.com Tue Feb 18 17:20:04 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Feb 2014 12:20:04 -0500 Subject: =?UTF-8?Q?=22Everyone_should_be_deployin?= =?UTF-8?Q?g_BCP_38!_Wait=2C_they_are_=E2=80=A6=2E=22?= Message-ID: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> Here's a piece which uses the MIT ANA data to assert that the job is mostly done already. Unless I'm very much mistaken, it appears that a large percentage of the failed BCP 38 spoofing tests listed in that data are actually due to customer side NAT routers dropping packets... which is of course egress filtering rather than ingress filtering, and thus doesn't actually apply to our questions. Am I interpreting that correctly? http://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/ (Oh, and bcp38.info is now the number 2 Ghit for "bcp38"; thanks to 5 new contributors for signing up to help so far this week.) Cheers, - jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From kamtha at ak-labs.net Tue Feb 18 17:50:19 2014 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Tue, 18 Feb 2014 12:50:19 -0500 Subject: looking for feedback on virtual/dedicated server providers in latin/south america/UK Message-ID: <20140218175019.GA15203@ak-labs.net> Hi, Just wondering if anyone could share some experiences with server providers specifically in argentina, columbia and costa rica, and pretty much anywhere in the UK region. Please respond offlist. Any feedback would be greatly appreciated. :) Carlos. From me at geordish.org Tue Feb 18 18:31:29 2014 From: me at geordish.org (Dave Bell) Date: Tue, 18 Feb 2014 18:31:29 +0000 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> Message-ID: That article is terrible. Looking at the stats provided, only 2582 unique AS's were tested. http://www.cidr-report.org/as2.0/#General_Status has over 46k AS's currently in the routing table. This means they have tested around 5% of the AS's on the Internet. Dave On 18 February 2014 17:20, Jay Ashworth wrote: > Here's a piece which uses the MIT ANA data to assert that the job is > mostly done already. > > Unless I'm very much mistaken, it appears that a large percentage of the > failed BCP 38 spoofing tests listed in that data are actually due to > customer side NAT routers dropping packets... > > which is of course egress filtering rather than ingress filtering, and > thus doesn't actually apply to our questions. > > Am I interpreting that correctly? > > http://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/ > > (Oh, and bcp38.info is now the number 2 Ghit for "bcp38"; thanks to 5 new > contributors for signing up to help so far this week.) > > Cheers, > - jra > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From patrick at ianai.net Tue Feb 18 18:40:52 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 18 Feb 2014 13:40:52 -0500 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> Message-ID: <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> Barry is a well respected security researcher. I'm surprised he posted this. In his defense, he did it over a year ago (June 11, 2012). Maybe we should ask him about it. I'll do that now.... -- TTFN, patrick On Feb 18, 2014, at 13:31 , Dave Bell wrote: > That article is terrible. > > Looking at the stats provided, only 2582 unique AS's were tested. > http://www.cidr-report.org/as2.0/#General_Status has over 46k AS's > currently in the routing table. > > This means they have tested around 5% of the AS's on the Internet. > > Dave > > > On 18 February 2014 17:20, Jay Ashworth wrote: > >> Here's a piece which uses the MIT ANA data to assert that the job is >> mostly done already. >> >> Unless I'm very much mistaken, it appears that a large percentage of the >> failed BCP 38 spoofing tests listed in that data are actually due to >> customer side NAT routers dropping packets... >> >> which is of course egress filtering rather than ingress filtering, and >> thus doesn't actually apply to our questions. >> >> Am I interpreting that correctly? >> >> http://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/ >> >> (Oh, and bcp38.info is now the number 2 Ghit for "bcp38"; thanks to 5 new >> contributors for signing up to help so far this week.) >> >> Cheers, >> - jra >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> > From sam at circlenet.us Tue Feb 18 19:00:37 2014 From: sam at circlenet.us (Sam Moats) Date: Tue, 18 Feb 2014 14:00:37 -0500 Subject: looking for feedback on virtual/dedicated server providers in latin/south america/UK In-Reply-To: <20140218175019.GA15203@ak-labs.net> References: <20140218175019.GA15203@ak-labs.net> Message-ID: <4206e1c12927ec382548894e1c92655f@www.circlenet.us> I have to recommend Linode in the UK, from my experience they have their act together and their prices are reasonable. Sam Moats Circle Net On 2014-02-18 12:50, Carlos Kamtha wrote: > Hi, > > Just wondering if anyone could share some experiences with > server providers specifically in argentina, columbia and costa rica, > and pretty much anywhere in the UK region. > > Please respond offlist. > > Any feedback would be greatly appreciated. :) > > Carlos. From LarrySheldon at cox.net Tue Feb 18 19:11:03 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 18 Feb 2014 13:11:03 -0600 Subject: =?windows-1252?Q?Re=3A_=22Everyone_should_be_deploying_?= =?windows-1252?Q?BCP_38!_Wait=2C_they_are_=85=2E=22?= In-Reply-To: References: Message-ID: <5303B047.5020701@cox.net> On 2/18/2014 11:20 AM, Jay Ashworth wrote: > Here's a piece which uses the MIT ANA data to assert that the job is > mostly done already. > > Unless I'm very much mistaken, it appears that a large percentage of > the failed BCP 38 spoofing tests listed in that data are actually due > to customer side NAT routers dropping packets... > > which is of course egress filtering rather than ingress filtering, > and thus doesn't actually apply to our questions. > > Am I interpreting that correctly? The date seems a little past "buy by" in light of the very recent observations and comments here. > http://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/ -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jmilko at bandwidth.com Tue Feb 18 19:19:34 2014 From: jmilko at bandwidth.com (James Milko) Date: Tue, 18 Feb 2014 14:19:34 -0500 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: <5303B047.5020701@cox.net> References: <5303B047.5020701@cox.net> Message-ID: Is using data from a self-selected group even meaningful when extrapolated? It's been a while since Stats in college, and it's very likely the guys from MIT know more than I do, but one of the big things they pushed was random sampling. JM On Tue, Feb 18, 2014 at 2:11 PM, Larry Sheldon wrote: > On 2/18/2014 11:20 AM, Jay Ashworth wrote: > >> Here's a piece which uses the MIT ANA data to assert that the job is >> mostly done already. >> >> Unless I'm very much mistaken, it appears that a large percentage of >> the failed BCP 38 spoofing tests listed in that data are actually due >> to customer side NAT routers dropping packets... >> >> which is of course egress filtering rather than ingress filtering, >> and thus doesn't actually apply to our questions. >> >> Am I interpreting that correctly? >> > > The date seems a little past "buy by" in light of the very recent > observations and comments here. > > http://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/ >> > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > From jared at puck.nether.net Tue Feb 18 19:22:13 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Feb 2014 14:22:13 -0500 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> Message-ID: On Feb 18, 2014, at 1:40 PM, Patrick W. Gilmore wrote: > Barry is a well respected security researcher. I'm surprised he posted this. > > In his defense, he did it over a year ago (June 11, 2012). Maybe we should ask him about it. I'll do that now.... I'm not surprised in any regard. There are too many names for BCP-38, SAV, SSAC-004, BCP-84, Ingress Filtering, etc.. There are many networks that perform this best practice either by "default" through NAT/firewalls or by explicit configuration of the devices. There are many networks that one will never be able to measure nor audit as well, but that doesn't mean we shouldn't continue to work on tracking back spoofed packets and reporting the attacks, and securing devices. - Jared From fergdawgster at mykolab.com Tue Feb 18 19:43:25 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 18 Feb 2014 11:43:25 -0800 Subject: Changing the way we talk about BCP38 [Was: Re: "Everyone should be deploying BCP 38! Wait, they are ...."] In-Reply-To: References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> Message-ID: <5303B7DD.9070507@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Below: On 2/18/2014 11:22 AM, Jared Mauch wrote: > > On Feb 18, 2014, at 1:40 PM, Patrick W. Gilmore > wrote: > >> Barry is a well respected security researcher. I'm surprised he >> posted this. >> >> In his defense, he did it over a year ago (June 11, 2012). Maybe >> we should ask him about it. I'll do that now.... > > I'm not surprised in any regard. There are too many names for > BCP-38, SAV, SSAC-004, BCP-84, Ingress Filtering, etc.. > This is why I am now using the phrase "anti-spoofing" when talking about this in public. It far less cryptic, and I am breaking into bite-sized components that people can actually understand. As engineers & technical people, we need to start using language people can wrap their brains around easily. Remember: We are living in the age of instant gratification and Attention Deficit Disorder. :-) - - ferg > There are many networks that perform this best practice either by > "default" through NAT/firewalls or by explicit configuration of the > devices. > > There are many networks that one will never be able to measure nor > audit as well, but that doesn't mean we shouldn't continue to work > on tracking back spoofed packets and reporting the attacks, and > securing devices. > > - Jared > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMDt90ACgkQKJasdVTchbIBrwD/YyUeK4SvS6grQdarKnoJiZXD 2YoTf+lRXpXnkSTPUdUA/3TH8jnXNx6DkOw9nkbVIi6Ek8ehTLUPpDPBe0oELQj4 =Cf2C -----END PGP SIGNATURE----- From eesslinger at fpu-tn.com Tue Feb 18 19:44:03 2014 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 18 Feb 2014 13:44:03 -0600 Subject: HP to Cisco fiber Message-ID: <489EAE655F69A246A2CBF4197BFD2511E13775A7@exchange.corp.fpu-tn.com> I've talked to HP and Cisco and neither side will commit to any kind of answer to this question, so I thought I'd ask it here: Does anyone know if a Cisco switch equipped with a 1000BASE-BX10-D SFP will connect to an HP switch equipped with a HP X122 1G SFP LC BX-U Transceiver J9143B SFP, assuming they are already talking over dual fiber links and both units support the single fiber sfp's? (they do). All the specs look like they should but Cisco and HP are doing the old 'will neither confirm nor deny interoperability'. Off list reply is fine, I'd like someone with a definite 'yes I did it and it works fine' or 'no I tried it and it did not', not 'it should' because that's where I'm at for the moment. ------------------------------------- Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpunet.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From jra at baylink.com Tue Feb 18 19:48:53 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Feb 2014 14:48:53 -0500 (EST) Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: Message-ID: <9905506.9062.1392752933874.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dave Bell" > That article is terrible. > > Looking at the stats provided, only 2582 unique AS's were tested. > http://www.cidr-report.org/as2.0/#General_Status has over 46k AS's > currently in the routing table. > > This means they have tested around 5% of the AS's on the Internet. Well, it did strike me, when someone cited the same data last week, that it seemed an awful lot of stew to make from that few oysters. I suppose it does depend on what percentage of end nodes are subsumed by those AS's, but there's no authoritative way to know that from on top. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Tue Feb 18 19:53:13 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Feb 2014 14:53:13 -0500 (EST) Subject: BCP38 filtering on Mobile IP networks Message-ID: <13397190.9066.1392753193876.JavaMail.root@benjamin.baylink.com> I note that the MIT ANA tester is only for desktop OSs, and none of the network tools I've collected for Android have BCP38 filter testing built in. Does anyone know if there are such tools for Android and for iOS? I assume that tether testing from a PC would be useless, as the NAT implementation would drop the packets -- does anyone know if there are any leaky NAT implementations that *won't* drop packets with bogus source addresses? Or, alternatively, does anyone know *authoritatively* that any cell carrier's mobile IP network already implements BCP38? And if so, why aren't they bragging about it; at least here? :-) I have added the Small Business page to BCP38.info. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jared at puck.nether.net Tue Feb 18 20:48:22 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Feb 2014 15:48:22 -0500 Subject: HP to Cisco fiber In-Reply-To: <489EAE655F69A246A2CBF4197BFD2511E13775A7@exchange.corp.fpu-tn.com> References: <489EAE655F69A246A2CBF4197BFD2511E13775A7@exchange.corp.fpu-tn.com> Message-ID: <02911AE8-1BC8-4E79-9163-1535F2FDC98A@puck.nether.net> On Feb 18, 2014, at 2:44 PM, Eric J Esslinger wrote: > I've talked to HP and Cisco and neither side will commit to any kind of answer to this question, so I thought I'd ask it here: > Does anyone know if a Cisco switch equipped with a 1000BASE-BX10-D SFP will connect to an HP switch equipped with a HP X122 1G SFP LC BX-U Transceiver J9143B SFP, assuming they are already talking over dual fiber links and both units support the single fiber sfp's? (they do). > > All the specs look like they should but Cisco and HP are doing the old 'will neither confirm nor deny interoperability'. > > Off list reply is fine, I'd like someone with a definite 'yes I did it and it works fine' or 'no I tried it and it did not', not 'it should' because that's where I'm at for the moment. Sounds like it should based on your description. You should make sure other media settings match, such as speed, etc.. While this may seem illogical on a 1G SFP, some devices have varying expectations of that, so sometimes "speed nonegotiate" is necessary. If you are going from HP-HP to Cisco-HP, you may need to disable their transciever eeprom check on the Cisco side. - Jared From rdrake at direcpath.com Tue Feb 18 20:56:19 2014 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 18 Feb 2014 15:56:19 -0500 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: References: <5303B047.5020701@cox.net> Message-ID: <5303C8F3.4000304@direcpath.com> On 2/18/2014 2:19 PM, James Milko wrote: > Is using data from a self-selected group even meaningful when > extrapolated? It's been a while since Stats in college, and it's very > likely the guys from MIT know more than I do, but one of the big things > they pushed was random sampling. > > JM > > Isn't it probable that people who know enough to download the spoofer projects program and run it might also be in position to fix things when it's broken, or they may just be testing their own networks which they've already secured, just to verify they got it right. I may put it on my laptop and start testing random places like Starbucks, my moms house, conventions and other things, but if I'm running it from my home machine it's just to get the gold "I did this" star. So yeah, data from the project is probably meaningless unless someone uses it as a worm payload and checks 50,000 computers randomly (of course I don't advise this. I just wish there was a way to really push this to be run by everyone in the world for a week) Maybe with enough hype we could get CNN to advise people to download it. Actually, it would be nice if someone who writes security software like NOD32 or Malwarebytes, or spybot, adaware, etc, would integrate it into their test suite. Then you get the thousands of users from them added to the results. From ttauber at 1-4-5.net Tue Feb 18 21:52:04 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 18 Feb 2014 16:52:04 -0500 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> Message-ID: I agree that Barry's post can be read in misleading ways and I seem to recall chatting about that with him at some point. As to one poster's comment about random sampling, I'm pretty sure the Spoofer project likely fell short in a number of ways (e.g. being documented in not every language). So, if NATs prevent (many? most?) end-user machines for being able inject spoofed IPv4 source addresses (IPv6 home gateways may well not provide such protection), maybe we should conclude that most of the spoofing is coming from somewhere else; perhaps including colo and cloud providers. I wonder how many users/admins of those kinds of machines ran the Spoofer test SW. Tony On Tue, Feb 18, 2014 at 2:22 PM, Jared Mauch wrote: > > On Feb 18, 2014, at 1:40 PM, Patrick W. Gilmore wrote: > > > Barry is a well respected security researcher. I'm surprised he posted > this. > > > > In his defense, he did it over a year ago (June 11, 2012). Maybe we > should ask him about it. I'll do that now.... > > I'm not surprised in any regard. There are too many names for BCP-38, > SAV, SSAC-004, BCP-84, Ingress Filtering, etc.. > > There are many networks that perform this best practice either by > "default" through NAT/firewalls or by explicit configuration of the devices. > > There are many networks that one will never be able to measure nor audit > as well, but that doesn't mean we shouldn't continue to work on tracking > back spoofed packets and reporting the attacks, and securing devices. > > - Jared > > > From jra at baylink.com Tue Feb 18 22:14:59 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Feb 2014 17:14:59 -0500 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: <5303C8F3.4000304@direcpath.com> References: <5303B047.5020701@cox.net> <5303C8F3.4000304@direcpath.com> Message-ID: <532898f0-cb0c-458c-8fbe-f2e88c30b89a@email.android.com> Spybot, adaware, and MalWare bytes. I hadn't even thought of them; I was all fixated on Ookla... and why it wouldn't work. I will query those folks. Cheers, - jra On February 18, 2014 3:56:19 PM EST, Robert Drake wrote: > >On 2/18/2014 2:19 PM, James Milko wrote: >> Is using data from a self-selected group even meaningful when >> extrapolated? It's been a while since Stats in college, and it's >very >> likely the guys from MIT know more than I do, but one of the big >things >> they pushed was random sampling. >> >> JM >> >> >Isn't it probable that people who know enough to download the spoofer >projects program and run it might also be in position to fix things >when >it's broken, or they may just be testing their own networks which >they've already secured, just to verify they got it right. > >I may put it on my laptop and start testing random places like >Starbucks, my moms house, conventions and other things, but if I'm >running it from my home machine it's just to get the gold "I did this" >star. > >So yeah, data from the project is probably meaningless unless someone >uses it as a worm payload and checks 50,000 computers randomly (of >course I don't advise this. I just wish there was a way to really push > >this to be run by everyone in the world for a week) > >Maybe with enough hype we could get CNN to advise people to download >it. Actually, it would be nice if someone who writes security software > >like NOD32 or Malwarebytes, or spybot, adaware, etc, would integrate it > >into their test suite. Then you get the thousands of users from them >added to the results. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From rdobbins at arbor.net Wed Feb 19 00:09:05 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 00:09:05 +0000 Subject: Changing the way we talk about BCP38 [Was: Re: "Everyone should be deploying BCP 38! Wait, they are ...."] In-Reply-To: <5303B7DD.9070507@mykolab.com> References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> <5303B7DD.9070507@mykolab.com> Message-ID: <1A1740DC-C816-4C07-9737-EC1D7D3B6734@arbor.net> On Feb 19, 2014, at 2:43 AM, Paul Ferguson wrote: > This is why I am now using the phrase "anti-spoofing" when talking about this in public. +1 It's also more semantically correct, in many cases. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From geraint at koding.com Wed Feb 19 00:24:18 2014 From: geraint at koding.com (Geraint Jones) Date: Wed, 19 Feb 2014 13:24:18 +1300 Subject: Fibre/Layer2 In San Jose Message-ID: Hi I am wondering if anyone knows anyone with Fibre or L2 service between Equinix SV1 (11 Great Oaks) and CoreSite (55 S Market). It seems we need it sooner rather than later. Thanks. -- Geraint Jones Director of Systems & Infrastructure Koding https://koding.com geraint at koding.com Phone (415) 653-0083 From rdobbins at arbor.net Wed Feb 19 00:56:28 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 00:56:28 +0000 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: References: <0291caab-41e9-4550-8b77-faf1ebff11e4@email.android.com> <72A422C9-40BE-4F19-A61F-70229C20D56D@ianai.net> Message-ID: <7255A53F-66D8-49D0-B2BC-7457D92ED636@arbor.net> On Feb 19, 2014, at 4:52 AM, Tony Tauber wrote: > maybe we should conclude that most of the spoofing is coming from somewhere else; perhaps including colo and cloud providers. My theory - not yet backed by data - is that probably most spoofed traffic these days does in fact emanate from IDC networks, and that a non-trivial proportion of same emanates from a relatively small number of such networks. In many cases, it's possible to put 'naked' hosts on home broadband connections, however - and how common that is, and what proportion of those broadband access networks don't run any form of anti-spoofing, is an open question. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From randy at psg.com Wed Feb 19 01:52:57 2014 From: randy at psg.com (Randy Bush) Date: Wed, 19 Feb 2014 09:52:57 +0800 Subject: spamassassin Message-ID: in the last 3-4 days, a *massive* amount of spam is making it past spamassassin to my users and to me. see appended for example. not all has dkim. clue? randy From: "SmallCapStockPlays" Subject: Could VIIC be our biggest play in 2014? Check the stock today To: Date: Tue, 18 Feb 2014 20:48:02 -0500 Return-path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ran.psg.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,MIME_QP_LONG_LINE,T_DKIM_INVALID autolearn=ham version=3.3.2 Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFwGl-0006al-Bu for randy at ran.psg.com; Wed, 19 Feb 2014 01:48:16 +0000 Received: from [207.254.213.223] (helo=drone166.ral.icpbounce.com) by psg.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WFwGZ-000Lp8-0W for randy at psg.com; Wed, 19 Feb 2014 01:48:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=default; d=icontactmail3.com; h=Mime-Version:From:To:Date:Subject:List-Unsubscribe:X-Feedback-ID:Content-Type:Message-ID; bh=iihwvTJA/ZrrgzXpk+9Muk0Sqlfk5BqD+aI+mL91kn8=; b=wKHIYdl1BdMRK0Kak5Z/2CwsfFh5Byoe9ZlHaqQz3VK4ltYtLfCI3tg6y8Wq3HuULY+ere7Fzz9Q camnKSvqcSx3u8LQWQGQSZoYkOmzcIemCHNNrsBD+WZhVA9R3W10V2NM6OTuJKFURxtmCNME29kH 5bYunRCoGolocQ5HmAw= Mime-Version: 1.0 Errors-To: bounces+796782.50654126.285374 at icpbounce.com List-Unsubscribe: , X-List-Unsubscribe: X-Unsubscribe-Web: X-Feedback-ID: 01_796782_285374:01_796782:01:vocus X-ICPINFO: X-Return-Path-Hint: bounces+796782.50654126.285374 at icpbounce.com Content-Type: multipart/alternative; boundary="cdf82e78-582d-4a55-9037-dacf81ae37d3" Message-ID: <0.1.F.AFD.1CF2D149FE8FD9E.0 at drone166.ral.icpbounce.com> [1 ] HOME ABOUT US TRADE IDEAS PENNY STOCK ARTICLES DAILY NEWS [1][png] [2][png] [3][png] From muhammad.adnan200 at gmail.com Tue Feb 18 21:09:12 2014 From: muhammad.adnan200 at gmail.com (Muhammad Adnan) Date: Tue, 18 Feb 2014 21:09:12 +0000 Subject: Work Practices of Cyber Security Professionals In-Reply-To: <256716.1392733735@turing-police.cc.vt.edu> References: <256716.1392733735@turing-police.cc.vt.edu> Message-ID: Dear Valdis, >1) If you're including network admins, you should also make sure to >get system admins (though you'll be more successful asking elsewhere for those). We are also targeting system admins. As I mentioned in my e-mail, "targeted participants for this survey are those who perform security related activities as a part of their job". After this sentence, I mentioned a couple of roles as an example. By those examples I meant "including but not limited to". >2) Having worn at least a partial hat of all those along my career, I'm >curious what sort of tools will improve work practices for all the groups >concerned. The goal of this project is not to improve the work practices for all the groups concerned. Instead, our aim is to first find out what cyber security professionals (we are using this term to define anyone who performs security related activities) do on day-to-day basis and which of their activities are relatively significant (i.e. performed frequently and require more time) than others. Once we establish that, then we will pick a couple of relatively significant activities from their workflow and build tools for those activities, following a user-centered design process. But, to get to that stage we first need to know that cyber security professionals do, how often they do that, and how much time they spend on doing that. Hope that answers you questions. Feel free to ask if you have anymore. Best wishes, Adnan On Tue, Feb 18, 2014 at 2:28 PM, wrote: > On Mon, 17 Feb 2014 15:27:25 +0000, Muhammad Adnan said: > > > I am a university researcher who is investigating the development of new, > > usable tools that will improve the work practices of cyber security > > professionals. As a first step to achieve this goal, I am undertaking a > > survey to gain an in-depth understanding of the day-to-day activities of > > cyber security professionals. The targeted participants for this survey > are > > those who perform security related activities as a part of their job > (e.g. > > security analysts, network administrators, penetration testers). > > Several comments: > > 1) If you're including network admins, you should also make sure to > get system admins (though you'll be more successful asking elsewhere for > those). > > 2) Having worn at least a partial hat of all those along my careeer, I'm > curious what sort of tools will improve work practices for all the groups > concerned. Probably the only place you'll find much overlap is in record > keeping - but even there the record keeping that a sysadmin needs to do for > changelogging their boxes is fairly different from what security analysts > working an incident and pen testers engaged in a test will need. There's > also the problem that many sites have their change logging integrated into > their version control system or other workflow software already... > > Good luck! > From nobody at snovc.com Wed Feb 19 02:10:25 2014 From: nobody at snovc.com (Private Sender) Date: Tue, 18 Feb 2014 18:10:25 -0800 Subject: spamassassin In-Reply-To: References: Message-ID: <53041291.4000702@snovc.com> Randy Bush wrote: > in the last 3-4 days, a *massive* amount of spam is making it past > spamassassin to my users and to me. see appended for example. not > all has dkim. > > clue? > > randy > > From: "SmallCapStockPlays" > Subject: Could VIIC be our biggest play in 2014? Check the stock today > To: > Date: Tue, 18 Feb 2014 20:48:02 -0500 > Return-path: > X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ran.psg.com > X-Spam-Level: > X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,MIME_QP_LONG_LINE,T_DKIM_INVALID autolearn=ham version=3.3.2 > Received: from psg.com ([2001:418:1::62]) > by ran.psg.com with esmtp (Exim 4.76) > (envelope-from ) > id 1WFwGl-0006al-Bu > for randy at ran.psg.com; Wed, 19 Feb 2014 01:48:16 +0000 > Received: from [207.254.213.223] (helo=drone166.ral.icpbounce.com) > by psg.com with esmtp (Exim 4.82 (FreeBSD)) > (envelope-from ) > id 1WFwGZ-000Lp8-0W > for randy at psg.com; Wed, 19 Feb 2014 01:48:04 +0000 > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=default; d=icontactmail3.com; h=Mime-Version:From:To:Date:Subject:List-Unsubscribe:X-Feedback-ID:Content-Type:Message-ID; bh=iihwvTJA/ZrrgzXpk+9Muk0Sqlfk5BqD+aI+mL91kn8=; b=wKHIYdl1BdMRK0Kak5Z/2CwsfFh5Byoe9ZlHaqQz3VK4ltYtLfCI3tg6y8Wq3HuULY+ere7Fzz9Q camnKSvqcSx3u8LQWQGQSZoYkOmzcIemCHNNrsBD+WZhVA9R3W10V2NM6OTuJKFURxtmCNME29kH 5bYunRCoGolocQ5HmAw= > Mime-Version: 1.0 > Errors-To: bounces+796782.50654126.285374 at icpbounce.com > List-Unsubscribe: , > X-List-Unsubscribe: > X-Unsubscribe-Web: > X-Feedback-ID: 01_796782_285374:01_796782:01:vocus > X-ICPINFO: > X-Return-Path-Hint: bounces+796782.50654126.285374 at icpbounce.com > Content-Type: multipart/alternative; boundary="cdf82e78-582d-4a55-9037-dacf81ae37d3" > Message-ID: <0.1.F.AFD.1CF2D149FE8FD9E.0 at drone166.ral.icpbounce.com> > > [1 ] > HOME ABOUT US TRADE IDEAS PENNY STOCK ARTICLES DAILY NEWS > > [1][png] [2][png] [3][png] > They are smart and dkim sign their messages; even though it's invalid I believe that's why it has such a low bayes score. It's getting marked as ham and not spam. Are you positive your definitions are still updating? From randy at psg.com Wed Feb 19 02:42:57 2014 From: randy at psg.com (Randy Bush) Date: Wed, 19 Feb 2014 10:42:57 +0800 Subject: spamassassin In-Reply-To: <53041291.4000702@snovc.com> References: <53041291.4000702@snovc.com> Message-ID: > They are smart and dkim sign their messages; even though it's invalid I > believe that's why it has such a low bayes score. lots of the spam getting through has no dkim > It's getting marked as ham and not spam. Are you positive your > definitions are still updating? sa-update has run. and it runs cleanly randy From mike at mtcc.com Wed Feb 19 03:04:26 2014 From: mike at mtcc.com (Michael Thomas) Date: Tue, 18 Feb 2014 19:04:26 -0800 Subject: spamassassin In-Reply-To: References: Message-ID: <53041F3A.3040003@mtcc.com> On 02/18/2014 05:52 PM, Randy Bush wrote: > in the last 3-4 days, a *massive* amount of spam is making it past > spamassassin to my users and to me. see appended for example. not > all has dkim. > > It's been a while since i've been in this world, but I wonder whether bayes filters are using the public key of the dkim selector as a token. if they don't change selectors/keys they'd probably be s-canned pretty quickly. It would require that the dkim subsystem talk to the bayes subsystem since the public key isn't in the signature, so i'm guessing not. Mike From jmaimon at ttec.com Wed Feb 19 03:08:10 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 18 Feb 2014 22:08:10 -0500 Subject: random dns queries with random sources Message-ID: <5304201A.3040508@ttec.com> Hey all, DNS amplification spoofed source attacks, I get that. I even thought I was getting mitigation down to acceptable levels. But now this. At different times during the previous days and on different resolvers, routers with proxy turned on, etc... Thousand of queries with thousands of source ip addresses. According to my logs, sources are not being repeated (or not with any significant frequency) What is the purpose of this? 18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query: swe.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:25.067 queries: info: client 4.109.210.187#55190: query: ngqrbwuzquz.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.105 queries: info: client 91.82.209.221#33924: query: bgbtqcdtzen.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.106 queries: info: client 6.29.8.224#4379: query: uehkaiy.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.106 queries: info: client 67.27.41.169#44000: query: yqv.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.107 queries: info: client 45.207.31.218#30585: query: e.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.644 queries: info: client 95.217.89.95#5396: query: bfpofpj.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:25.823 queries: info: client 89.47.129.187#12316: query: aocdesguijxym.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:26.021 queries: info: client 15.205.106.62#34265: query: xqgyahfugnt.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:26.057 queries: info: client 128.64.33.29#7584: query: ijwhqfmpohmj.5kkx.com IN A + (216.222.148.103) 18-Feb-2014 21:45:26.330 queries: info: client 102.206.85.254#8093: query: ibojknsrqjohib.5kkx.com IN A + (216.222.148.103) 18-Feb-2014 21:45:26.333 queries: info: client 40.121.221.81#10822: query: ebb.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:26.752 queries: info: client 104.55.169.43#30108: query: l.5kkx.com IN A + (66.199.132.7) From ops.lists at gmail.com Wed Feb 19 03:10:39 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 18 Feb 2014 19:10:39 -0800 Subject: spamassassin In-Reply-To: References: Message-ID: DKIM serves to authenticate the source of the message. So this is a stock tip spam sent through an email service provider called icontact, and the dkim signature declares that. Just that and nothing more. Says nothing at all about the email's reputation - whether it is spam or not. --srs On Tuesday, February 18, 2014, Randy Bush wrote: > in the last 3-4 days, a *massive* amount of spam is making it past > spamassassin to my users and to me. see appended for example. not > all has dkim. > > clue? > > -- --srs (iPad) From LarrySheldon at cox.net Wed Feb 19 03:10:59 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 18 Feb 2014 21:10:59 -0600 Subject: spamassassin In-Reply-To: References: <53041291.4000702@snovc.com> Message-ID: <530420C3.3020604@cox.net> On 2/18/2014 8:42 PM, Randy Bush wrote: >> They are smart and dkim sign their messages; even though it's invalid I >> believe that's why it has such a low bayes score. > > lots of the spam getting through has no dkim > >> It's getting marked as ham and not spam. Are you positive your >> definitions are still updating? > > sa-update has run. and it runs cleanly > > randy > > From a posting on NANAE: > On 2/18/2014 6:09 PM, Larry Sheldon wrote: >> Received: from [207.254.213.223] (helo=drone166.ral.icpbounce.com) > > Larry, icpbounce.com is IContact aka Vocus. I don't know whether the > managers of Vocus are as whitehat as those of IContact were before the > buyout, but Andrew Barrett was still in charge of abuse/deliverability > when I last checked and he *does* respond quickly and effectively to > spam complaints. Try sending this to abuse at icontact.com. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From marka at isc.org Wed Feb 19 03:17:39 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Feb 2014 14:17:39 +1100 Subject: random dns queries with random sources In-Reply-To: Your message of "Tue, 18 Feb 2014 22:08:10 -0500." <5304201A.3040508@ttec.com> References: <5304201A.3040508@ttec.com> Message-ID: <20140219031740.06107FAB251@rock.dv.isc.org> In message <5304201A.3040508 at ttec.com>, Joe Maimon writes: > Hey all, > > DNS amplification spoofed source attacks, I get that. I even thought I > was getting mitigation down to acceptable levels. > > But now this. At different times during the previous days and on > different resolvers, routers with proxy turned on, etc... > > Thousand of queries with thousands of source ip addresses. > > According to my logs, sources are not being repeated (or not with any > significant frequency) > > What is the purpose of this? Indirect attack on the 5kkx.com servers? > 18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query: > swe.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:25.067 queries: info: client 4.109.210.187#55190: > query: ngqrbwuzquz.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.105 queries: info: client 91.82.209.221#33924: > query: bgbtqcdtzen.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.106 queries: info: client 6.29.8.224#4379: query: > uehkaiy.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.106 queries: info: client 67.27.41.169#44000: > query: yqv.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.107 queries: info: client 45.207.31.218#30585: > query: e.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.644 queries: info: client 95.217.89.95#5396: query: > bfpofpj.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:25.823 queries: info: client 89.47.129.187#12316: > query: aocdesguijxym.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:26.021 queries: info: client 15.205.106.62#34265: > query: xqgyahfugnt.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:26.057 queries: info: client 128.64.33.29#7584: query: > ijwhqfmpohmj.5kkx.com IN A + (216.222.148.103) > 18-Feb-2014 21:45:26.330 queries: info: client 102.206.85.254#8093: > query: ibojknsrqjohib.5kkx.com IN A + (216.222.148.103) > 18-Feb-2014 21:45:26.333 queries: info: client 40.121.221.81#10822: > query: ebb.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:26.752 queries: info: client 104.55.169.43#30108: > query: l.5kkx.com IN A + (66.199.132.7) > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ml at kenweb.org Wed Feb 19 03:19:17 2014 From: ml at kenweb.org (ML) Date: Tue, 18 Feb 2014 22:19:17 -0500 Subject: random dns queries with random sources In-Reply-To: <5304201A.3040508@ttec.com> References: <5304201A.3040508@ttec.com> Message-ID: <530422B5.4060008@kenweb.org> I couldn't resolve that domain or subdomains that I tried. If that domain did respond, I'd guess it's tailored to be a large junky response. Varying the qname prevents people from using iptables to block specific queries. On 2/18/2014 10:08 PM, Joe Maimon wrote: > Hey all, > > DNS amplification spoofed source attacks, I get that. I even thought I > was getting mitigation down to acceptable levels. > > But now this. At different times during the previous days and on > different resolvers, routers with proxy turned on, etc... > > Thousand of queries with thousands of source ip addresses. > > According to my logs, sources are not being repeated (or not with any > significant frequency) > > What is the purpose of this? > > 18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: > query: swe.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:25.067 queries: info: client 4.109.210.187#55190: > query: ngqrbwuzquz.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.105 queries: info: client 91.82.209.221#33924: > query: bgbtqcdtzen.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.106 queries: info: client 6.29.8.224#4379: query: > uehkaiy.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.106 queries: info: client 67.27.41.169#44000: > query: yqv.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.107 queries: info: client 45.207.31.218#30585: > query: e.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.644 queries: info: client 95.217.89.95#5396: > query: bfpofpj.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:25.823 queries: info: client 89.47.129.187#12316: > query: aocdesguijxym.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:26.021 queries: info: client 15.205.106.62#34265: > query: xqgyahfugnt.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:26.057 queries: info: client 128.64.33.29#7584: > query: ijwhqfmpohmj.5kkx.com IN A + (216.222.148.103) > 18-Feb-2014 21:45:26.330 queries: info: client 102.206.85.254#8093: > query: ibojknsrqjohib.5kkx.com IN A + (216.222.148.103) > 18-Feb-2014 21:45:26.333 queries: info: client 40.121.221.81#10822: > query: ebb.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:26.752 queries: info: client 104.55.169.43#30108: > query: l.5kkx.com IN A + (66.199.132.7) > From jmaimon at ttec.com Wed Feb 19 03:32:03 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 18 Feb 2014 22:32:03 -0500 Subject: random dns queries with random sources In-Reply-To: <20140219031740.06107FAB251@rock.dv.isc.org> References: <5304201A.3040508@ttec.com> <20140219031740.06107FAB251@rock.dv.isc.org> Message-ID: <530425B3.3070008@ttec.com> Mark Andrews wrote: >> What is the purpose of this? > > Indirect attack on the 5kkx.com servers? > >> 18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query: >> swe.5kkx.com IN A + (66.199.132.5) I have seen dozens of different second level parts. How is this any more effective then sending it direct? From dougb at dougbarton.us Wed Feb 19 03:35:25 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 18 Feb 2014 19:35:25 -0800 Subject: random dns queries with random sources In-Reply-To: <5304201A.3040508@ttec.com> References: <5304201A.3040508@ttec.com> Message-ID: <5304267D.3030508@dougbarton.us> On 02/18/2014 07:08 PM, Joe Maimon wrote: > Thousand of queries with thousands of source ip addresses. Pardon if I missed a memo, but how are your resolver systems receiving these thousands of very different source addresses? Doug From wbailey at satelliteintelligencegroup.com Wed Feb 19 03:38:34 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 19 Feb 2014 03:38:34 +0000 Subject: random dns queries with random sources In-Reply-To: <5304267D.3030508@dougbarton.us> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> Message-ID: Totally was trying to figure out how to ask the same thing. How exactly are you the POC in this situation? lol On 2/18/14, 7:35 PM, "Doug Barton" wrote: >On 02/18/2014 07:08 PM, Joe Maimon wrote: >> Thousand of queries with thousands of source ip addresses. > >Pardon if I missed a memo, but how are your resolver systems receiving >these thousands of very different source addresses? > >Doug > From rdobbins at arbor.net Wed Feb 19 03:44:30 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 03:44:30 +0000 Subject: random dns queries with random sources In-Reply-To: <5304201A.3040508@ttec.com> References: <5304201A.3040508@ttec.com> Message-ID: On Feb 19, 2014, at 10:08 AM, Joe Maimon wrote: > What is the purpose of this? Resource-exhaustion attack against the recursive DNS? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Wed Feb 19 03:46:39 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 03:46:39 +0000 Subject: random dns queries with random sources In-Reply-To: <530425B3.3070008@ttec.com> References: <5304201A.3040508@ttec.com> <20140219031740.06107FAB251@rock.dv.isc.org> <530425B3.3070008@ttec.com> Message-ID: On Feb 19, 2014, at 10:32 AM, Joe Maimon wrote: > How is this any more effective then sending it direct? If they're attacking the authoritative DNS servers for 5kkx.com, just reflecting gives them indirection and presumably makes traceback harder for 5kkx.com (at least, in the minds of the attackers). Or maybe they're trying to game 5kkx.com into blocking requests from the recursive servers in question, for some reason. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From morrowc.lists at gmail.com Wed Feb 19 03:47:01 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Feb 2014 22:47:01 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: On Tue, Feb 18, 2014 at 10:44 PM, Dobbins, Roland wrote: > > On Feb 19, 2014, at 10:08 AM, Joe Maimon wrote: > >> What is the purpose of this? > > Resource-exhaustion attack against the recursive DNS? so... i could be nuts, but in the example joe clipped, the resolved hosts are either: 66.199.132.5 66.199.132.7 or 216.222.148.103 these are from 2 different PI blocks, but the same named end-user: chl.net. maybe someone's upset with CHL, whomever that may be. From rdobbins at arbor.net Wed Feb 19 03:47:29 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 03:47:29 +0000 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: On Feb 19, 2014, at 10:44 AM, Dobbins, Roland wrote: > Resource-exhaustion attack against the recursive DNS? Fat-finger, sorry - should also state 'Or against the authoritative servers for 5kkx.com?' ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From morrowc.lists at gmail.com Wed Feb 19 03:48:18 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Feb 2014 22:48:18 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: On Tue, Feb 18, 2014 at 10:47 PM, Christopher Morrow wrote: > On Tue, Feb 18, 2014 at 10:44 PM, Dobbins, Roland wrote: >> >> On Feb 19, 2014, at 10:08 AM, Joe Maimon wrote: >> >>> What is the purpose of this? >> >> Resource-exhaustion attack against the recursive DNS? > > so... i could be nuts, but in the example joe clipped, the resolved > hosts are either: > 66.199.132.5 > 66.199.132.7 > or > 216.222.148.103 > > these are from 2 different PI blocks, but the same named end-user: chl.net. > > maybe someone's upset with CHL, whomever that may be. apologies. both chl.net and chl.com ... which appear to be parts of ttec ... which is joe. From george.herbert at gmail.com Wed Feb 19 03:49:36 2014 From: george.herbert at gmail.com (George Herbert) Date: Tue, 18 Feb 2014 19:49:36 -0800 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: Right. Nonzero chances that you (Joe's site) are the target... Also, check if you have egress filtering of spoofed addresses below these DNS resources, between them and any user objects. You could be sourcing the spoofing if not... On Tue, Feb 18, 2014 at 7:44 PM, Dobbins, Roland wrote: > > On Feb 19, 2014, at 10:08 AM, Joe Maimon wrote: > > > What is the purpose of this? > > Resource-exhaustion attack against the recursive DNS? > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- -george william herbert george.herbert at gmail.com From jmaimon at ttec.com Wed Feb 19 03:59:53 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 18 Feb 2014 22:59:53 -0500 Subject: random dns queries with random sources In-Reply-To: <5304267D.3030508@dougbarton.us> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> Message-ID: <53042C39.5020303@ttec.com> Doug Barton wrote: > On 02/18/2014 07:08 PM, Joe Maimon wrote: >> Thousand of queries with thousands of source ip addresses. > > Pardon if I missed a memo, but how are your resolver systems receiving > these thousands of very different source addresses? > > Doug > > Thousands of queries _from_ thousands of source ip addresses likely they are spoofed this is an example of what I am seeing root at nameserver3:~# baddnsqueries-srcs 9aq.com | wc -l 1337 root at nameserver3:~# grep 9aq.com /var/log/named/queries | wc -l 1415 root at nameserver3:~# baddnsqueries-srcs 9aq.com | sort -rn -k2 | head -n5 99.86.116.243 1 99.219.232.72 1 99.184.19.178 1 99.155.180.193 1 99.129.26.85 1 root at nameserver3:~# grep 9aq.com /var/log/named/queries | head -n5 18-Feb-2014 22:42:30.754 queries: info: client 93.209.49.151#59706: query: abpdefguvwxym.dlq1.9aq.com IN A + (66.199.132.5) 18-Feb-2014 22:42:30.787 queries: info: client 110.158.165.119#32438: query: ocpkxdfupiy.dlq1.9aq.com IN A + (66.199.132.7) 18-Feb-2014 22:42:31.382 queries: info: client 84.14.84.205#63722: query: abpqeftuiwklz.dlq1.9aq.com IN A + (66.199.132.7) 18-Feb-2014 22:42:31.649 queries: info: client 45.73.65.145#38948: query: pvtlirr.dlq1.9aq.com IN A + (66.199.132.7) 18-Feb-2014 22:42:32.679 queries: info: client 9.121.56.232#18395: query: amo.dlq1.9aq.com IN A + (66.199.132.5) root at nameserver3:~# cat /usr/local/sbin/baddnsqueries-srcs #!/bin/bash if [[ "$1" == "" ]]; then exit 0; fi grep -E "$1" /var/log/named/queries | cut -f6 -d' ' | cut -f1 -d# | sort | uniq |\ while read INPUT; do if [[ "$INPUT" == "" ]]; then continue; fi echo $INPUT `grep $INPUT /var/log/named/queries | grep -c -E "$1"`; done From jmaimon at ttec.com Wed Feb 19 04:00:03 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 18 Feb 2014 23:00:03 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: <53042C43.2090006@ttec.com> Dobbins, Roland wrote: > > On Feb 19, 2014, at 10:08 AM, Joe Maimon wrote: > >> What is the purpose of this? > > Resource-exhaustion attack against the recursive DNS? > On anything that is going to stay open, not even close. From nobody at snovc.com Wed Feb 19 04:01:58 2014 From: nobody at snovc.com (Private Sender) Date: Tue, 18 Feb 2014 20:01:58 -0800 Subject: spamassassin In-Reply-To: References: Message-ID: <53042CB6.60304@snovc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/18/2014 7:10 PM, Suresh Ramasubramanian wrote: > DKIM serves to authenticate the source of the message. So this is a stock > tip spam sent through an email service provider called icontact, and the > dkim signature declares that. Just that and nothing more. > > Says nothing at all about the email's reputation - whether it is spam or > not. > > --srs > > On Tuesday, February 18, 2014, Randy Bush wrote: > - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/18/2014 7:10 PM, Suresh Ramasubramanian wrote: > DKIM serves to authenticate the source of the message. So this is a stock > tip spam sent through an email service provider called icontact, and the > dkim signature declares that. Just that and nothing more. > > Says nothing at all about the email's reputation - whether it is spam or > not. > > --srs > > On Tuesday, February 18, 2014, Randy Bush wrote: > Yeah, it just validates the domain that the email came from. But, "X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ran.psg.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,MIME_QP_LONG_LINE,*T_DKIM_INVALID* autolearn=ham version=3.3.2" Spamassassin knows the dkim signature is invalid, so there must be a dns query that occurs at this point in the message processing. If that is the case, there must be someway to configure to reject if the dkim signature is invalid. "X-Spam-Status: No, score=0.8 required=5.0" Spamassassin isn't going to block anything until it registers a score of 5. So, just having a dkim signature (even though invalid) is possibly lowering the score. Maybe you could tweak the settings to pick-off spam at a lower score. But, setting your levels down to 0.8 would probably block legitimate email. You could always block their ip in the helo_access (or iptables) of your postfix server (I'm assuming that's what you are using). But that's only going to be a temporary fix. You could also add a rbl query to your mail server config to spamhaus. That could always help. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTBCy2AAoJEMBLKVFKNw4KFDUH/RktUI0ybOj0ruWw06RZUzcD bHiFb/QUahqXihFQMkSwofjV/WovcGkSQgCpzM3XFyGdoo79KzgJ9ByrlPLfIOdI m/pvcRSODl+rOsaXR1VS0bUyTtdRzEdRZ2EQxvXeaSIOnsZCegG+noY+7GJ5U70o NyctfgEod0sxFqeJKTzjXpCaXJsuwFBUL3PlLXVWE6ilAtaxh8KBCmIG/kFMrtoG P+DlTm17d63WZeVBvsZ7YHe/moVm57gBLCsmA8aI6qgqdCGbpkT3p/rKAEcqeV6z RyyIC4vm9gaaJmuh7Cz7hoM2whGsWSxfrNaGV0hCRoNGBAup5NFIQQfsTn858Dc= =Aztz -----END PGP SIGNATURE----- From rdobbins at arbor.net Wed Feb 19 04:07:24 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 04:07:24 +0000 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: On Feb 19, 2014, at 10:48 AM, Christopher Morrow wrote: > apologies. both chl.net and chl.com ... which appear to be parts of ttec ... which is joe. Premature send - I meant to add 'Or against the authoritative servers for 5kkx.com?' We've been seeing a spate of reflected (not amplified) DNS attacks against various authoritative servers in Europe for the past week or so, bounced through some type of consumer DSL broadband CPE with an open DNS forwarded on the WAN interface (don't know the make/model, but it was supplied by the broadband operators to the customers), on some European broadband access networks. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From dougb at dougbarton.us Wed Feb 19 04:25:35 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 18 Feb 2014 20:25:35 -0800 Subject: random dns queries with random sources In-Reply-To: <53042C39.5020303@ttec.com> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> Message-ID: <5304323F.3020405@dougbarton.us> On 02/18/2014 07:59 PM, Joe Maimon wrote: > > > Doug Barton wrote: >> On 02/18/2014 07:08 PM, Joe Maimon wrote: >>> Thousand of queries with thousands of source ip addresses. >> >> Pardon if I missed a memo, but how are your resolver systems receiving >> these thousands of very different source addresses? >> >> Doug >> >> > > Thousands of queries _from_ thousands of source ip addresses > > likely they are spoofed Yes, got that bit. :) What I'm asking is, why are spoofed queries hitting your "different resolvers, routers with proxy turned on, etc.?" Are you running open resolvers? If so, please stop doing that, it's widely known to be a bad idea for over a decade now, and you are providing the bad guys a tool to use for DDOS attacks. If it's something else, please speak up. Regardless of the goal of this particular issue, the way to solve the root problem is to prevent the spoofed packets from getting to your servers in the first place. Doug From ops.lists at gmail.com Wed Feb 19 04:44:25 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 18 Feb 2014 20:44:25 -0800 Subject: spamassassin In-Reply-To: <53042CB6.60304@snovc.com> References: <53042CB6.60304@snovc.com> Message-ID: I would not advise that. Plenty of things can render a dkim sig invalid. Not all of them are evidences of malice. You might be well advised to check for a DMARC record (which asserts policy using a combination of DKIM and SPF) and if there's a reject there, feel free to trash the email if there's a validation failure. But not simply because a DKIM signature breaks. --srs On Tuesday, February 18, 2014, Private Sender wrote: > Spamassassin knows the dkim signature is invalid, so there must be a dns > query that occurs at this point in the message processing. > > If that is the case, there must be someway to configure to reject if the > dkim signature is invalid. > > -- --srs (iPad) From jmaimon at ttec.com Wed Feb 19 05:44:43 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 00:44:43 -0500 Subject: random dns queries with random sources In-Reply-To: <5304323F.3020405@dougbarton.us> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> <5304323F.3020405@dougbarton.us> Message-ID: <530444CB.3010907@ttec.com> Doug Barton wrote: > On 02/18/2014 07:59 PM, Joe Maimon wrote: > Are you running open resolvers? Yes > If so, please stop doing that, No > it's > widely known to be a bad idea for over a decade now, At this point, doing anything on the internet is a bad idea. > and you are > providing the bad guys a tool to use for DDOS attacks. Get back to me when the same cant be done with auth servers. > > If it's something else, please speak up. Regardless of the goal of this > particular issue, the way to solve the root problem is to prevent the > spoofed packets from getting to your servers in the first place. > > Doug > > > From jmaimon at ttec.com Wed Feb 19 05:48:20 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 00:48:20 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> Message-ID: <530445A4.7090808@ttec.com> George Herbert wrote: > Right. Nonzero chances that you (Joe's site) are the target... > > Also, check if you have egress filtering of spoofed addresses below these > DNS resources, between them and any user objects. You could be sourcing > the spoofing if not... It seems to me that the same|similar dataset of open resolvers to be used for amplification attacks is also being used for this sort of thing, and the overall effect is not large enough to indicate my resources are a target. What I cant figure out is what is the target and how this attack method is any more effective then the others. Joe From rdobbins at arbor.net Wed Feb 19 05:50:59 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 05:50:59 +0000 Subject: random dns queries with random sources In-Reply-To: <530444CB.3010907@ttec.com> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> <5304323F.3020405@dougbarton.us> <530444CB.3010907@ttec.com> Message-ID: On Feb 19, 2014, at 12:44 PM, Joe Maimon wrote: > Get back to me when the same cant be done with auth servers. There are ways to deal with it on authoritative servers, like RRL. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Wed Feb 19 05:53:42 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 05:53:42 +0000 Subject: random dns queries with random sources In-Reply-To: <530445A4.7090808@ttec.com> References: <5304201A.3040508@ttec.com> <530445A4.7090808@ttec.com> Message-ID: On Feb 19, 2014, at 12:48 PM, Joe Maimon wrote: > What I cant figure out is what is the target and how this attack method is any more effective then the others. The target appears to be the authoritative servers for the domain in question, yes? The attacker may consider it more effective because it provides a degree of obfuscation, or maybe he has some reason to game the operators of the authoritative servers in question into denying requests from your recursors. Most (not all) attackers don't know that much about TCP/IP, DNS, et. al, and they tend to copycat one another and do the same things due to magical thinking. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From owen at delong.com Wed Feb 19 05:56:03 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Feb 2014 21:56:03 -0800 Subject: random dns queries with random sources In-Reply-To: <530445A4.7090808@ttec.com> References: <5304201A.3040508@ttec.com> <530445A4.7090808@ttec.com> Message-ID: <043E2776-2F76-427B-B46A-474777FFA711@delong.com> On Feb 18, 2014, at 9:48 PM, Joe Maimon wrote: > > > George Herbert wrote: >> Right. Nonzero chances that you (Joe's site) are the target... >> >> Also, check if you have egress filtering of spoofed addresses below these >> DNS resources, between them and any user objects. You could be sourcing >> the spoofing if not... > > It seems to me that the same|similar dataset of open resolvers to be used for amplification attacks is also being used for this sort of thing, and the overall effect is not large enough to indicate my resources are a target. > > What I cant figure out is what is the target and how this attack method is any more effective then the others. > > Joe This assumes several facts not in evidence: 1. It is an attack. 2. It is deliberate 3. There is a target 4. It is more effective than others On what do you base those assumptions? To me this looks to be far more likely to be someone?s wayward script, experiment, software, tool, etc. doing something it probably isn?t supposed to be doing. If it happens to also be gathering the answers or information that the author wants (or appears to be doing so), then the author may well be blissfully ignorant of its wayward behavior towards your servers. Owen From jmaimon at ttec.com Wed Feb 19 06:07:16 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 01:07:16 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> <5304323F.3020405@dougbarton.us> <530444CB.3010907@ttec.com> Message-ID: <53044A14.30205@ttec.com> Dobbins, Roland wrote: > > On Feb 19, 2014, at 12:44 PM, Joe Maimon wrote: > >> Get back to me when the same cant be done with auth servers. > > There are ways to deal with it on authoritative servers, like RRL. > There are ways to deal with it on resolvers as well, like RRL and IDS and iptables and see google for so more examples. From jmaimon at ttec.com Wed Feb 19 06:11:28 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 01:11:28 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> <530445A4.7090808@ttec.com> Message-ID: <53044B10.7060009@ttec.com> Dobbins, Roland wrote: > > On Feb 19, 2014, at 12:48 PM, Joe Maimon wrote: > >> What I cant figure out is what is the target and how this attack method is any more effective then the others. > > The target appears to be the authoritative servers for the domain in question, yes? I dont think so, but I have not compiled the full list of domains and compared the auth servers for each. > > The attacker may consider it more effective because it provides a degree of obfuscation, or maybe he has some reason to game the operators of the authoritative servers in question into denying requests from your recursors. > > Most (not all) attackers don't know that much about TCP/IP, DNS, et. al, and they tend to copycat one another and do the same things due to magical thinking. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > > From rdobbins at arbor.net Wed Feb 19 06:16:39 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 06:16:39 +0000 Subject: random dns queries with random sources In-Reply-To: <53044A14.30205@ttec.com> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> <5304323F.3020405@dougbarton.us> <530444CB.3010907@ttec.com> <53044A14.30205@ttec.com> Message-ID: On Feb 19, 2014, at 1:07 PM, Joe Maimon wrote: > There are ways to deal with it on resolvers as well, like RRL and IDS and iptables None of these things work well for recursive resolvers; they cause more problems than they solve. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From randy at psg.com Wed Feb 19 06:20:37 2014 From: randy at psg.com (Randy Bush) Date: Wed, 19 Feb 2014 14:20:37 +0800 Subject: spamassassin In-Reply-To: <53042CB6.60304@snovc.com> References: <53042CB6.60304@snovc.com> Message-ID: as i said, much of the crap coming through, 10-20 times normal, does not have dkim. i suggest that focusing on dkim is a red herring. and yes, i know how dkim works. > If that is the case, there must be someway to configure to reject if the > dkim signature is invalid. 5.0-0.8 is a large valus, at least in this area. > You could always block their ip in the ... their? you are presuming a single soure. > You could also add a rbl query to your mail server config to spamhaus. have had that for years randy From jmaimon at ttec.com Wed Feb 19 06:28:38 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 01:28:38 -0500 Subject: random dns queries with random sources In-Reply-To: <043E2776-2F76-427B-B46A-474777FFA711@delong.com> References: <5304201A.3040508@ttec.com> <530445A4.7090808@ttec.com> <043E2776-2F76-427B-B46A-474777FFA711@delong.com> Message-ID: <53044F16.9020708@ttec.com> Owen DeLong wrote: > > On Feb 18, 2014, at 9:48 PM, Joe Maimon wrote: > > This assumes several facts not in evidence: > > 1. It is an attack. > 2. It is deliberate > 3. There is a target > 4. It is more effective than others > > On what do you base those assumptions? To me this looks to be far more likely to be someone?s wayward script, experiment, software, tool, etc. doing something it probably isn?t supposed to be doing. I have found this occurring on unaffiliated open resolvers (that I happen to support and that I was able to make the choice to close) It has been ongoing for a week or so (but not constant). The domain names have a pattern but are comprised of components that appear to be randomly generated. The source IP addresses for the queries appear to be non duplicated and randomly generated. query logs are available for unicasting to the interested. Has nobody else seen this? > > If it happens to also be gathering the answers or information that the author wants (or appears to be doing so), then the author may well be blissfully ignorant of its wayward behavior towards your servers. > > Owen > > > I would like to figure out how. Joe From jmaimon at ttec.com Wed Feb 19 06:30:56 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 01:30:56 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> <5304323F.3020405@dougbarton.us> <530444CB.3010907@ttec.com> <53044A14.30205@ttec.com> Message-ID: <53044FA0.8010802@ttec.com> Dobbins, Roland wrote: > > On Feb 19, 2014, at 1:07 PM, Joe Maimon wrote: > >> There are ways to deal with it on resolvers as well, like RRL and IDS and iptables > > None of these things work well for recursive resolvers; they cause more problems than they solve. > Whatever I am doing appears to be working, at least until this cropped up. Joe From DStaal at usa.net Wed Feb 19 06:46:33 2014 From: DStaal at usa.net (Daniel Staal) Date: Wed, 19 Feb 2014 01:46:33 -0500 Subject: spamassassin In-Reply-To: References: Message-ID: --As of February 19, 2014 9:52:57 AM +0800, Randy Bush is alleged to have said: > in the last 3-4 days, a *massive* amount of spam is making it past > spamassassin to my users and to me. see appended for example. not > all has dkim. > > clue? --As for the rest, it is mine. The spamassassin list has been tracking an issue where a new rule made it out of the testbox accidentally, which lowers scores on a lot of spam. It wasn't in the sample you provided, but the rule name is BAYES_999 - it catches mail that the bayes filter thinks is 99.9-100% sure to be spam. As it got promoted prematurely, it's showing with a score of 1.0. (The default.) It's probably a part of your problem. A fix should be in the rules update today or tomorrow - or you can rescore it to the same as BAYES_99 (someplace in the 3 range by default, I believe). That's what used to catch that mail: it used to mean 99-100%, and now means 99-99.9%. More info can be found in the mailing list archives for the spamassassin list. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From randy at psg.com Wed Feb 19 07:03:27 2014 From: randy at psg.com (Randy Bush) Date: Wed, 19 Feb 2014 15:03:27 +0800 Subject: spamassassin In-Reply-To: References: Message-ID: > A fix should be in the rules update today or tomorrow - or you can rescore > it to the same as BAYES_99 (someplace in the 3 range by default, I > believe). That's what used to catch that mail: it used to mean 99-100%, > and now means 99-99.9%. trying the copy 99->999 now. thanks! randy From me at anuragbhatia.com Wed Feb 19 08:35:04 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 19 Feb 2014 16:35:04 +0800 Subject: random dns queries with random sources In-Reply-To: <53044FA0.8010802@ttec.com> References: <5304201A.3040508@ttec.com> <5304267D.3030508@dougbarton.us> <53042C39.5020303@ttec.com> <5304323F.3020405@dougbarton.us> <530444CB.3010907@ttec.com> <53044A14.30205@ttec.com> <53044FA0.8010802@ttec.com> Message-ID: Hello everyone I can see such crap traffic from over couple of weeks now but yes it appeared all of sudden and I was also wondering if I am alone experiencing it. 2014-02-19 14:30 GMT+08:00 Joe Maimon : > > > Dobbins, Roland wrote: > >> >> On Feb 19, 2014, at 1:07 PM, Joe Maimon wrote: >> >> There are ways to deal with it on resolvers as well, like RRL and IDS >>> and iptables >>> >> >> None of these things work well for recursive resolvers; they cause more >> problems than they solve. >> >> > Whatever I am doing appears to be working, at least until this cropped up. > > Joe > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From sthaug at nethelp.no Wed Feb 19 09:18:23 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 19 Feb 2014 10:18:23 +0100 (CET) Subject: random dns queries with random sources In-Reply-To: References: Message-ID: <20140219.101823.74675943.sthaug@nethelp.no> > Premature send - I meant to add 'Or against the authoritative servers for 5kkx.com?' > > We've been seeing a spate of reflected (not amplified) DNS attacks against various authoritative servers in Europe for the past week or so, bounced through some type of consumer DSL broadband CPE with an open DNS forwarded on the WAN interface (don't know the make/model, but it was supplied by the broadband operators to the customers), on some European broadband access networks. Pretty clearly an attack against various authoritative servers. Right now I'm seeing attacks against the following domains / name servers: comedc.com NS f1g1ns1.dnspod.net vip1.zndns.com v1s1.xundns.com jd176.com NS ns{1,2}.dnsabc-g.com x7ok.com NS safe.qycn.{com,org,net,cn} bdhope.com NS ns{1,2}.dnsabc-b.com yg521.com NS dns{1,2,3,4,5,6}.iidns.com 56bj56.com NS ns{1,2}.dnsabc-f.com This is all detected in AS 2116 - unfortunately we have our share of customers with open resolvers / broadband routers with DNS proxies open towards the WAN side. Steinar Haug, AS 2116 From sthaug at nethelp.no Wed Feb 19 09:26:23 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 19 Feb 2014 10:26:23 +0100 (CET) Subject: random dns queries with random sources In-Reply-To: <53044F16.9020708@ttec.com> References: <530445A4.7090808@ttec.com> <043E2776-2F76-427B-B46A-474777FFA711@delong.com> <53044F16.9020708@ttec.com> Message-ID: <20140219.102623.41709393.sthaug@nethelp.no> > It has been ongoing for a week or so (but not constant). The domain > names have a pattern but are comprised of components that appear to be > randomly generated. The source IP addresses for the queries appear to be > non duplicated and randomly generated. > > query logs are available for unicasting to the interested. > > Has nobody else seen this? We've seen it. It is pretty clearly an attack against authoritative name servers for various domains, using open recursors or proxies to reflect the queries. Steinar Haug, AS 2116 From piu at pmgroupuk.com Wed Feb 19 13:02:03 2014 From: piu at pmgroupuk.com (Praveen Unnikrishnan) Date: Wed, 19 Feb 2014 13:02:03 +0000 Subject: GEO location issue with google In-Reply-To: References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: <61045cf146f149808cc074563268c634@DB3PR04MB026.eurprd04.prod.outlook.com> Hi Heather, Thanks you very much for sorting out this issue. Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: piu at pmgroupuk.com [cid:image004.png at 01CF2D72.C52965E0] [cid:image002.jpg at 01CE1663.96B300D0] www.pmgroupuk.com | www.pmgchosting.com How am I doing? Contact my manager, click here. ________________________________ [cid:image003.jpg at 01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC? is a registered trademark of PMGC Technology Group Ltd. From: Heather Schiller [mailto:has at google.com] Sent: 13 February 2014 05:43 To: Praveen Unnikrishnan Cc: nanog at nanog.org Subject: Re: GEO location issue with google Reported to the appropriate folks. Going to www.google.co.uk directly, should return you English language results. Appending /en to the end of a google url should also return you English language results. You should also be able to set your language preference in your search settings. --Heather On Fri, Feb 7, 2014 at 10:20 AM, Praveen Unnikrishnan > wrote: Hi, We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. Could anyone please help me to sort this out? Would be much appreciated for your time. Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: piu at pmgroupuk.com> [cid:image001.png at 01CF2418.27F29CA0] [cid:image002.jpg at 01CE1663.96B300D0] www.pmgroupuk.com | www.pmgchosting.com How am I doing? Contact my manager, click here?subject=How's%20Praveen%20doing?>. ________________________________ [cid:image003.jpg at 01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC(r) is a registered trademark of PMGC Technology Group Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6879 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 14829 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 184 bytes Desc: image004.png URL: From simon.perreault at viagenie.ca Wed Feb 19 14:46:55 2014 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Wed, 19 Feb 2014 09:46:55 -0500 Subject: spamassassin In-Reply-To: References: Message-ID: <5304C3DF.8000805@viagenie.ca> Daniel is correct, he gets a cookie! The the others: please learn to recognize when you have no clue. We've been having the same problem here for the last three days. I tracked it down to BAYES_999. Glad to see other people are suffering as much as I am. :) Simon Le 2014-02-19 01:46, Daniel Staal a ?crit : > --As of February 19, 2014 9:52:57 AM +0800, Randy Bush is alleged to > have said: > >> in the last 3-4 days, a *massive* amount of spam is making it past >> spamassassin to my users and to me. see appended for example. not >> all has dkim. >> >> clue? > > --As for the rest, it is mine. > > The spamassassin list has been tracking an issue where a new rule made > it out of the testbox accidentally, which lowers scores on a lot of > spam. It wasn't in the sample you provided, but the rule name is > BAYES_999 - it catches mail that the bayes filter thinks is 99.9-100% > sure to be spam. As it got promoted prematurely, it's showing with a > score of 1.0. (The default.) It's probably a part of your problem. > > A fix should be in the rules update today or tomorrow - or you can > rescore it to the same as BAYES_99 (someplace in the 3 range by default, > I believe). That's what used to catch that mail: it used to mean > 99-100%, and now means 99-99.9%. > > More info can be found in the mailing list archives for the spamassassin > list. > > Daniel T. Staal -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Davis.Beeman at integratelecom.com Wed Feb 19 15:57:36 2014 From: Davis.Beeman at integratelecom.com (Beeman, Davis) Date: Wed, 19 Feb 2014 15:57:36 +0000 Subject: random dns queries with random sources In-Reply-To: <5304201A.3040508@ttec.com> References: <5304201A.3040508@ttec.com> Message-ID: <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> I am late to this train, but it appears no one else has brought this up. It is a DNS tunneling setup, not an attack. I have been dealing with one of these lately as well. They were using some open resolvers in my network to reflect, but the "random" hostnames in the queries are tunneled traffic or keywords. The original sources of the traffic are probably members of a botnet, and this is being used as a sneaky C&C method. Due to the tiny amount of data you can send in the DNS query name field, this will sort of look like an attack, because they have to send thousands of queries to get anything done. They are not attacking the authoritative name servers in those domains, as has been suggested, rather the authoritative name server in these domains is the rouge DNS server in use by the bad actor running a botnet. Davis Beeman Network Security Engineer -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Tuesday, February 18, 2014 19:08 To: North American Networking and Offtopic Gripes List Subject: random dns queries with random sources Hey all, DNS amplification spoofed source attacks, I get that. I even thought I was getting mitigation down to acceptable levels. But now this. At different times during the previous days and on different resolvers, routers with proxy turned on, etc... Thousand of queries with thousands of source ip addresses. According to my logs, sources are not being repeated (or not with any significant frequency) What is the purpose of this? 18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query: swe.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:25.067 queries: info: client 4.109.210.187#55190: query: ngqrbwuzquz.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.105 queries: info: client 91.82.209.221#33924: query: bgbtqcdtzen.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.106 queries: info: client 6.29.8.224#4379: query: uehkaiy.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.106 queries: info: client 67.27.41.169#44000: query: yqv.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.107 queries: info: client 45.207.31.218#30585: query: e.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:25.644 queries: info: client 95.217.89.95#5396: query: bfpofpj.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:25.823 queries: info: client 89.47.129.187#12316: query: aocdesguijxym.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:26.021 queries: info: client 15.205.106.62#34265: query: xqgyahfugnt.5kkx.com IN A + (66.199.132.7) 18-Feb-2014 21:45:26.057 queries: info: client 128.64.33.29#7584: query: ijwhqfmpohmj.5kkx.com IN A + (216.222.148.103) 18-Feb-2014 21:45:26.330 queries: info: client 102.206.85.254#8093: query: ibojknsrqjohib.5kkx.com IN A + (216.222.148.103) 18-Feb-2014 21:45:26.333 queries: info: client 40.121.221.81#10822: query: ebb.5kkx.com IN A + (66.199.132.5) 18-Feb-2014 21:45:26.752 queries: info: client 104.55.169.43#30108: query: l.5kkx.com IN A + (66.199.132.7) From rdobbins at arbor.net Wed Feb 19 16:28:17 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 19 Feb 2014 16:28:17 +0000 Subject: random dns queries with random sources In-Reply-To: <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> References: <5304201A.3040508@ttec.com> <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> Message-ID: On Feb 19, 2014, at 10:57 PM, Beeman, Davis wrote: > I am late to this train, but it appears no one else has brought this up. It is a DNS tunneling setup, not an attack. This makes a lot of sense - good insight, will look into this further! ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From simon.perreault at viagenie.ca Wed Feb 19 16:32:49 2014 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Wed, 19 Feb 2014 11:32:49 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> Message-ID: <5304DCB1.4050408@viagenie.ca> Le 2014-02-19 11:28, Dobbins, Roland a ?crit : >> I am late to this train, but it appears no one else has brought this up. It is a DNS tunneling setup, not an attack. > > This makes a lot of sense - good insight, will look into this further! I use this for free wi-fi in airports and such: http://code.kryo.se/iodine/ If the wi-fi is configured to use an open resolver, we end up with the situation you describe. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tempestterror at gmail.com Wed Feb 19 16:38:03 2014 From: tempestterror at gmail.com (Tempest) Date: Wed, 19 Feb 2014 08:38:03 -0800 Subject: random dns queries with random sources In-Reply-To: <5304DCB1.4050408@viagenie.ca> References: <5304201A.3040508@ttec.com> <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> <5304DCB1.4050408@viagenie.ca> Message-ID: Or if you tell your bots to use a set of open resolvers, it helps hide them by a step. On Wed, Feb 19, 2014 at 8:32 AM, Simon Perreault < simon.perreault at viagenie.ca> wrote: > Le 2014-02-19 11:28, Dobbins, Roland a ?crit : > >> I am late to this train, but it appears no one else has brought this > up. It is a DNS tunneling setup, not an attack. > > > > This makes a lot of sense - good insight, will look into this further! > > I use this for free wi-fi in airports and such: > > http://code.kryo.se/iodine/ > > If the wi-fi is configured to use an open resolver, we end up with the > situation you describe. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > From cgrundemann at gmail.com Wed Feb 19 16:43:35 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 19 Feb 2014 09:43:35 -0700 Subject: Deadline Approaching [was: Ad Hoc BCOP Committee - Call for Volunteers] Message-ID: Hello again NANOGers, FYI - The deadline for BCOP committee nominations is 28 February. We have received several great candidates already and are hoping to receive several more! If you are interested in joining this grassroots effort to make the Internet a safer, more predictable place (or know someone who should) - please send an email with a brief bio to betty at nanog.org ASAP. We'll be kicking off committee calls in early March! =) Thanks! ~Chris On Fri, Jan 31, 2014 at 1:56 PM, Chris Grundemann wrote: > Hail NANOGers! > > Per approval of the NANOG Board in February 2013, a community effort to > develop a NANOG sponsored regional BCOP effort was engaged. NANOG BCOP > Tracks and updates were provided at RIPE, ARIN, NANOG 57, 58, and 59. > > In November of 2013, sufficient interest and momentum in the NANOG BCOP > effort emerged. On November 21, 2013, the NANOG Board approved the > appointment of an Ad Hoc Committee Chair who would report to the Board and > direct the efforts of NANOG-BCOP. > > I have agreed to serve as Chair and am now seeking volunteers to continue > with the important work of the committee. Please consider volunteering your > time and effort in support of this important NANOG activity! > > To help guide you, please review the following committee expectations: > > Strategies and Goals: > * Support an open, transparent, and bottom-up/grassroots process for the > creation of current > and living practical network operation documentation > * Facilitate the development of mutually rewarding documents and guides > * Maintain the sense of community and accessibility in BCOP materials > * Develop and deploy a portfolio of guides that meet the needs of the > broad range of NANOG operators > > Deliverables: > * Responsible for recruiting a minimum of 1 shepard per calendar year. > * Responsible for recruiting a minimum of 1 author per calendar year. > * Required to attend at least 75% of all scheduled committee calls. > * Expected to attend 66% of all NANOG meetings over the course of your > two-year term. > * A BCOP Ad Hoc Committee Member is expected to volunteer up to 10 hours > in the 12 weeks Leading into a NANOG meeting and an additional 15 hours all > year round > > Also see the website at http://bcop.nanog.org for more information. > > If you are interested in participating, please send your short bio to > Betty Burke, NANOG Executive Director, betty at nanog.org. Betty can also > answer any and all questions you may have. Betty or I will be sure to > follow-up with each volunteer and get our important work underway as soon > as possible. > > Cheers, > ~Chris > > -- > @ChrisGrundemann > http://chrisgrundemann.com > -- @ChrisGrundemann http://chrisgrundemann.com From jmaimon at ttec.com Wed Feb 19 16:59:04 2014 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Feb 2014 11:59:04 -0500 Subject: random dns queries with random sources In-Reply-To: <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> References: <5304201A.3040508@ttec.com> <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> Message-ID: <5304E2D8.40809@ttec.com> Beeman, Davis wrote: > rather the authoritative name server in these domains is the rouge DNS server in use by the bad actor running a botnet. > > Davis Beeman > Network Security Engineer Somebody must be registering these domain names. And I should be able to compile a list of the auth servers in question. Joe From Davis.Beeman at integratelecom.com Wed Feb 19 17:08:03 2014 From: Davis.Beeman at integratelecom.com (Beeman, Davis) Date: Wed, 19 Feb 2014 17:08:03 +0000 Subject: random dns queries with random sources In-Reply-To: <5304E2D8.40809@ttec.com> References: <5304201A.3040508@ttec.com> <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> <5304E2D8.40809@ttec.com> Message-ID: <2AF841AB78217140A2A394B2BB6D39C5037B449A@IDCPRDMBX2.ads.integratelecom.com> They are, and dropping them just as fast. It seems like the last a day or two, and then move on to another domain name. They are similar enough that the bots probably work off a formula to determine valid requests. It may be a coincidence, if you believe in those, but this type of C&C traffic started ramping up wildly about a month after the ZeroAccess servers got blocked... Davis Beeman | Network Security Engineer | 360.816.3052 Integra -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Wednesday, February 19, 2014 08:59 To: Beeman, Davis; North American Networking and Offtopic Gripes List Subject: Re: random dns queries with random sources Beeman, Davis wrote: > rather the authoritative name server in these domains is the rouge DNS server in use by the bad actor running a botnet. > > Davis Beeman > Network Security Engineer Somebody must be registering these domain names. And I should be able to compile a list of the auth servers in question. Joe From rvandolson at esri.com Wed Feb 19 17:57:26 2014 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 19 Feb 2014 09:57:26 -0800 Subject: Looking for an Amazon EC2 East Contact Message-ID: <20140219175725.GA22384@esri.com> Seeing pretty consistent packet loss to/from instances in EC2 East (54.80 IPs) from various vantage points. Working through normal support channels, but looking for a contact to help expedite. Thanks, Ray From phil.gardnerjr at gmail.com Wed Feb 19 18:14:43 2014 From: phil.gardnerjr at gmail.com (Phil Gardner) Date: Wed, 19 Feb 2014 13:14:43 -0500 Subject: VMware Training Message-ID: <5304F493.4040106@gmail.com> Not sure if this list is the best place, but it is probably the only list that I'm on that won't give me a bunch of grief about the chosen technology. I looked at VMware's site, and there are a ton of options. I'm wondering if anyone has some basic suggestions or experiences. I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm sufficiently versed in deploying scripted ESXi (including 5.x) installations for a specific environment, including vswitches/SAN config (but only with NFS datastores backed by a NetApp, unfortunately, no blockbased stores). I'd like to get experience deploying VCenter clusters, down to DRS/HA config, other block based storage, and anything else a large environment needs. Thoughts or experiences? -- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538 From eugen at imacandi.net Wed Feb 19 18:36:41 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 19 Feb 2014 20:36:41 +0200 Subject: VMware Training In-Reply-To: <5304F493.4040106@gmail.com> References: <5304F493.4040106@gmail.com> Message-ID: On Wed, Feb 19, 2014 at 8:14 PM, Phil Gardner wrote: > Not sure if this list is the best place, but it is probably the only list > that I'm on that won't give me a bunch of grief about the chosen technology. > > I looked at VMware's site, and there are a ton of options. I'm wondering > if anyone has some basic suggestions or experiences. > > I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm > sufficiently versed in deploying scripted ESXi (including 5.x) > installations for a specific environment, including vswitches/SAN config > (but only with NFS datastores backed by a NetApp, unfortunately, no > blockbased stores). > If you want block storage, just export an iSCSI device to the ESXi machines (tgtadm on RedHat is all you need and a few gigs of free space). VMFS is cluster aware so you can export the same volume to independent ESXi hosts and as long you don't access the same files, you're good to go. > > I'd like to get experience deploying VCenter clusters, down to DRS/HA > config, other block based storage, and anything else a large environment > needs. > > All you need is licenses (Enterprise Plus to get all the nice features) and a vCenter server. If you already have it, just create a new cluster and follow the prompts in the wizards and play with all the options. > Thoughts or experiences? > > When I first started with this it seemed like rocket science, but once you create a cluster and do DRS/HA/dvSwitch/etc it's all pretty basic: - HA in VMware means that if a host fails, the VMs will be restarted on a different host. - DRS it means automated live migration of virtual machines based on load. - dvSwitch is a distributed virtual switch whereby you have a consistent configuration across the hosts that you configure from the vCenter server. If you know RedHat, than from experience in a few days you can learn the ins/outs of how a VMware cluster works. With ESXi 5.1+ you can run ESXi inside an ESXi host so if you have a lot of memory on a host you can create your own little lab with all the features and experiment with them. If you want to certify, than official training is a mandatory requirement. HTH, Eugeniu From itsmemattchung at gmail.com Wed Feb 19 18:37:54 2014 From: itsmemattchung at gmail.com (Matt Chung) Date: Wed, 19 Feb 2014 12:37:54 -0600 Subject: VMware Training In-Reply-To: <5304F493.4040106@gmail.com> References: <5304F493.4040106@gmail.com> Message-ID: Hey Phil, I recently did the VCP certification/course through VMWare however I was working with the technology over the past 5 years. Based off your desire to gain experience with it, my recommendation is to load up VMware Workstation on your computer and deploy ESXi instances as the guests. This is a cost feasible and although performance won't be production grade, you have the ability to play with clusters, DRS/HA config, OpenSAN (for your block based storage), etc. There is a myriad of training docs available but if you do want the certification itself, you'll have to go through the official course(s). Cheers, Matt Chung On Wed, Feb 19, 2014 at 12:14 PM, Phil Gardner wrote: > Not sure if this list is the best place, but it is probably the only list > that I'm on that won't give me a bunch of grief about the chosen technology. > > I looked at VMware's site, and there are a ton of options. I'm wondering > if anyone has some basic suggestions or experiences. > > I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm > sufficiently versed in deploying scripted ESXi (including 5.x) > installations for a specific environment, including vswitches/SAN config > (but only with NFS datastores backed by a NetApp, unfortunately, no > blockbased stores). > > I'd like to get experience deploying VCenter clusters, down to DRS/HA > config, other block based storage, and anything else a large environment > needs. > > Thoughts or experiences? > > -- > _____________________ > Phil Gardner > PGP Key ID 0xFECC890C > OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538 > > -- -Matt Chung From jra at baylink.com Wed Feb 19 20:06:06 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Feb 2014 15:06:06 -0500 (EST) Subject: VMware Training In-Reply-To: Message-ID: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eugeniu Patrascu" > If you want block storage, just export an iSCSI device to the ESXi machines > (tgtadm on RedHat is all you need and a few gigs of free space). VMFS is > cluster aware so you can export the same volume to independent ESXi hosts > and as long you don't access the same files, you're good to go. My understanding of "cluster-aware filesystem" was "can be mounted at the physical block level by multiple operating system instances with complete safety". That seems to conflict with what you suggest, Eugeniu; am I missing something (as I often do)? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From dale.rumph at gmail.com Wed Feb 19 16:11:35 2014 From: dale.rumph at gmail.com (Dale Rumph) Date: Wed, 19 Feb 2014 11:11:35 -0500 Subject: random dns queries with random sources In-Reply-To: <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> References: <5304201A.3040508@ttec.com> <2AF841AB78217140A2A394B2BB6D39C5037B41EE@IDCPRDMBX2.ads.integratelecom.com> Message-ID: Davis, Having seen this in the past, and managing both open resolvers and authoritative servers for several large eyeball networks, I think your assumption is correct this definitely smells like C&C traffic being handled via DNS. Just my 2c - YMMV - All sales final, As is - Dale Rumph - Network Engineer/Security Consultant On Feb 19, 2014 10:58 AM, "Beeman, Davis" wrote: > I am late to this train, but it appears no one else has brought this up. > It is a DNS tunneling setup, not an attack. I have been dealing with one > of these lately as well. They were using some open resolvers in my network > to reflect, but the "random" hostnames in the queries are tunneled traffic > or keywords. The original sources of the traffic are probably members of a > botnet, and this is being used as a sneaky C&C method. Due to the tiny > amount of data you can send in the DNS query name field, this will sort of > look like an attack, because they have to send thousands of queries to get > anything done. > > They are not attacking the authoritative name servers in those domains, as > has been suggested, rather the authoritative name server in these domains > is the rouge DNS server in use by the bad actor running a botnet. > > Davis Beeman > Network Security Engineer > > > -----Original Message----- > From: Joe Maimon [mailto:jmaimon at ttec.com] > Sent: Tuesday, February 18, 2014 19:08 > To: North American Networking and Offtopic Gripes List > Subject: random dns queries with random sources > > Hey all, > > DNS amplification spoofed source attacks, I get that. I even thought I was > getting mitigation down to acceptable levels. > > But now this. At different times during the previous days and on different > resolvers, routers with proxy turned on, etc... > > Thousand of queries with thousands of source ip addresses. > > According to my logs, sources are not being repeated (or not with any > significant frequency) > > What is the purpose of this? > > 18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query: > swe.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:25.067 queries: info: client 4.109.210.187#55190: > query: ngqrbwuzquz.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.105 queries: info: client 91.82.209.221#33924: > query: bgbtqcdtzen.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.106 queries: info: client 6.29.8.224#4379: query: > uehkaiy.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.106 queries: info: client 67.27.41.169#44000: > query: yqv.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.107 queries: info: client 45.207.31.218#30585: > query: e.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:25.644 queries: info: client 95.217.89.95#5396: query: > bfpofpj.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:25.823 queries: info: client 89.47.129.187#12316: > query: aocdesguijxym.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:26.021 queries: info: client 15.205.106.62#34265: > query: xqgyahfugnt.5kkx.com IN A + (66.199.132.7) > 18-Feb-2014 21:45:26.057 queries: info: client 128.64.33.29#7584: query: > ijwhqfmpohmj.5kkx.com IN A + (216.222.148.103) > 18-Feb-2014 21:45:26.330 queries: info: client 102.206.85.254#8093: > query: ibojknsrqjohib.5kkx.com IN A + (216.222.148.103) > 18-Feb-2014 21:45:26.333 queries: info: client 40.121.221.81#10822: > query: ebb.5kkx.com IN A + (66.199.132.5) > 18-Feb-2014 21:45:26.752 queries: info: client 104.55.169.43#30108: > query: l.5kkx.com IN A + (66.199.132.7) > > > From mohta at necom830.hpcl.titech.ac.jp Wed Feb 19 21:39:22 2014 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 20 Feb 2014 06:39:22 +0900 Subject: random dns queries with random sources In-Reply-To: <5304201A.3040508@ttec.com> References: <5304201A.3040508@ttec.com> Message-ID: <5305248A.4030406@necom830.hpcl.titech.ac.jp> Joe Maimon wrote: > What is the purpose of this? It may be an experiment that rate limiting is useless to suppress amplification against attacks simultaneously on many targets. A better protection should be to shutdown secure DNS, which is not very secure. Masataka Ohta From rdrake at direcpath.com Wed Feb 19 22:02:53 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 19 Feb 2014 17:02:53 -0500 Subject: GEO location issue with google In-Reply-To: <61045cf146f149808cc074563268c634@DB3PR04MB026.eurprd04.prod.outlook.com> References: <55ca3f74d398416e975212b074831d71@DB3PR04MB026.eurprd04.prod.outlook.com> <61045cf146f149808cc074563268c634@DB3PR04MB026.eurprd04.prod.outlook.com> Message-ID: <53052A0D.1090206@direcpath.com> For future reference, the last time this issue came up someone said doing this was a good way to get their geo stuff fixed automatically: http://tools.ietf.org/html/draft-google-self-published-geofeeds-02 I haven't messed with it yet, but it seems like a good idea. I want to write something that lets me export this from our IPAM but I've been busy and it isn't a problem for us at the moment. Thanks, Robert On 2/19/2014 8:02 AM, Praveen Unnikrishnan wrote: > Hi Heather, > > Thanks you very much for sorting out this issue. > > Praveen Unnikrishnan > Network Engineer > PMGC Technology Group Ltd > T: 020 3542 6401 > M: 07827921390 > F: 087 1813 1467 > E: piu at pmgroupuk.com > > [cid:image004.png at 01CF2D72.C52965E0] > > > [cid:image002.jpg at 01CE1663.96B300D0] > www.pmgroupuk.com | www.pmgchosting.com > How am I doing? Contact my manager, click here. > > ________________________________ > [cid:image003.jpg at 01CE1663.96B300D0] > > PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. > > PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. > > PMGC? is a registered trademark of PMGC Technology Group Ltd. > > > From: Heather Schiller [mailto:has at google.com] > Sent: 13 February 2014 05:43 > To: Praveen Unnikrishnan > Cc: nanog at nanog.org > Subject: Re: GEO location issue with google > > Reported to the appropriate folks. > > Going to www.google.co.uk directly, should return you English language results. Appending /en to the end of a google url should also return you English language results. You should also be able to set your language preference in your search settings. > > --Heather > > On Fri, Feb 7, 2014 at 10:20 AM, Praveen Unnikrishnan > wrote: > Hi, > > We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. > > Could anyone please help me to sort this out? > > Would be much appreciated for your time. > > Praveen Unnikrishnan > Network Engineer > PMGC Technology Group Ltd > T: 020 3542 6401 > M: 07827921390 > F: 087 1813 1467 > E: piu at pmgroupuk.com> > > [cid:image001.png at 01CF2418.27F29CA0] > > > [cid:image002.jpg at 01CE1663.96B300D0] > www.pmgroupuk.com | www.pmgchosting.com > How am I doing? Contact my manager, click here?subject=How's%20Praveen%20doing?>. > > ________________________________ > [cid:image003.jpg at 01CE1663.96B300D0] > > PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com. > > PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. > > PMGC(r) is a registered trademark of PMGC Technology Group Ltd. > > -- Direcpath, LLC 817 West Peachtree St. NW - Suite 750 | Atlanta, GA 30308 2935B Amwiler Rd. | Atlanta,GA 30360 T 866-430-7284 | F 404.961.7060 rdrake at direcpath.com | www.direcpath.com From stenn at ntp.org Wed Feb 19 20:48:55 2014 From: stenn at ntp.org (Harlan Stenn) Date: Wed, 19 Feb 2014 20:48:55 +0000 Subject: NTP DRDos Blog post Message-ID: Folks, I just posted http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ . In general we've never allowed comments to blog posts on that site; we're currently discussing if we should allow them for this post. I'd love to hear any feedback about the post. Thanks... -- Harlan Stenn http://networktimefoundation.org - be a member! From randy at psg.com Thu Feb 20 02:48:49 2014 From: randy at psg.com (Randy Bush) Date: Thu, 20 Feb 2014 10:48:49 +0800 Subject: spamassassin In-Reply-To: <5304C3DF.8000805@viagenie.ca> References: <5304C3DF.8000805@viagenie.ca> Message-ID: > Daniel is correct, he gets a cookie! The the others: please learn to > recognize when you have no clue. simon, you just do not understand the purpose of the nanog list > We've been having the same problem here for the last three days. I > tracked it down to BAYES_999. Glad to see other people are suffering > as much as I am. :) as the fix is not yet out, would be cool if someone with more fu than i posted a recipe to hack for the moment. randy From gem at rellim.com Thu Feb 20 03:01:50 2014 From: gem at rellim.com (Gary E. Miller) Date: Wed, 19 Feb 2014 19:01:50 -0800 Subject: spamassassin In-Reply-To: References: <5304C3DF.8000805@viagenie.ca> Message-ID: <20140219190150.35f3a504.gem@rellim.com> Yo Randy! On Thu, 20 Feb 2014 10:48:49 +0800 Randy Bush wrote: > > We've been having the same problem here for the last three days. I > > tracked it down to BAYES_999. Glad to see other people are suffering > > as much as I am. :) > > as the fix is not yet out, would be cool if someone with more fu than > i posted a recipe to hack for the moment. http://www.gossamer-threads.com/lists/spamassassin/users/183433 body BAYES_99 eval:check_bayes('0.99', '0.999') body BAYES_999 eval:check_bayes('0.999', '1.00') score BAYES_99 0 0 3.8 3.5 score BAYES_999 0 0 4.0 3.7 RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From andris at hpl.hp.com Thu Feb 20 03:06:25 2014 From: andris at hpl.hp.com (Andris Kalnozols) Date: Wed, 19 Feb 2014 19:06:25 -0800 Subject: spamassassin In-Reply-To: References: <5304C3DF.8000805@viagenie.ca> Message-ID: <53057131.3050806@hpl.hp.com> On 2/19/2014 6:48 PM, Randy Bush wrote: >> Daniel is correct, he gets a cookie! The the others: please learn to >> recognize when you have no clue. > > simon, you just do not understand the purpose of the nanog list > >> We've been having the same problem here for the last three days. I >> tracked it down to BAYES_999. Glad to see other people are suffering >> as much as I am. :) > > as the fix is not yet out, would be cool if someone with more fu than i > posted a recipe to hack for the moment. I found this config. block in the file "50_scores.cf" and added the BAYES_999 entry: > # make the Bayes scores unmutable (as discussed in bug 4505) > ifplugin Mail::SpamAssassin::Plugin::Bayes > score BAYES_00 0 0 -1.5 -1.9 > score BAYES_05 0 0 -0.3 -0.5 > score BAYES_20 0 0 -0.001 -0.001 > score BAYES_40 0 0 -0.001 -0.001 > score BAYES_50 0 0 2.0 0.8 > score BAYES_60 0 0 2.5 1.5 > score BAYES_80 0 0 2.7 2.0 > score BAYES_95 0 0 3.2 3.0 > score BAYES_99 0 0 3.8 3.5 > score BAYES_999 0 0 4.0 3.9 > endif ------ Andris From randy at psg.com Thu Feb 20 03:22:34 2014 From: randy at psg.com (Randy Bush) Date: Thu, 20 Feb 2014 11:22:34 +0800 Subject: spamassassin In-Reply-To: <20140219190150.35f3a504.gem@rellim.com> References: <5304C3DF.8000805@viagenie.ca> <20140219190150.35f3a504.gem@rellim.com> Message-ID: > http://www.gossamer-threads.com/lists/spamassassin/users/183433 as blabby as nanog, and not really specific > body BAYES_99 eval:check_bayes('0.99', '0.999') > body BAYES_999 eval:check_bayes('0.999', '1.00') > score BAYES_99 0 0 3.8 3.5 > score BAYES_999 0 0 4.0 3.7 and this is a replacement for both 999 and 99? randy From mysidia at gmail.com Thu Feb 20 03:24:30 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 19 Feb 2014 21:24:30 -0600 Subject: VMware Training In-Reply-To: <5304F493.4040106@gmail.com> References: <5304F493.4040106@gmail.com> Message-ID: On Wed, Feb 19, 2014 at 12:14 PM, Phil Gardner wrote: Seeing you are a Linux admin; VMware's prof. training offerings are basic "point and click" things, not very Linux-admin friendly; no advanced subjects or even CLI usage in "Install, Configure, Manage". If you are already at the level of doing scripted ESXi installs and configuring hosts for SAN storage and networking according to VMware's best practices, then you should be able to work out the little that is left by reading the ample documentation and a few whitepapers, unless you need proof of completing a class as a certification pre-requisite. One way to get the extra experiences would be to start by putting together the simplest two-node or three node cluster you can muster; try various configurations, put it through its paces: make it break in every conceivable way, fix it.... There is almost nothing extra to do for DRS/HA config, other than to design the networking, storage, compute, and DNS properly to be resilient and support them. You literally just check a box to turn on DRS, and a box to turn on HA, select an admission policy, and select automation level and migration threshold. Of course, there are advanced options, and 'exotic' clusters where you need to know the magic option names. You may also need to specify additional isolation IP addresses, or tweak timeouts for VMware tools heartbeat monitoring, to cut down on unwanted false HA restarts. These are not things you will find in the training classes; you need to read the documentation and literature contained on various blogs --- it would probably be best to read some of Duncan Epping and Scott Lowe's books; if you have the time, and to further solidify understanding. Ultimately; you are not going to be able to do this realistically, without real servers comparable to the real world, so a laptop running ESXi may not be enough. You could also find a company to lease you some lab hours to tinker with other storage technology; i'm sure by now there are online cloud-based Rent-A-Labs with the EMC VNX/Dell Equallogic/HP storage hardware. >vswitches/SAN config (but only with NFS datastores backed by a NetApp, unfortunately, Also... with uh... NetApp units running current software at least can very easily create an extra block-based lun on top of a volume, to be served out as a block target. You might want to ask your storage vendor support what it would take to get the keycode to turn on FC or iSCSI licenses, so you can present an extra 40gb scratch volume...... Or you could download the Netapp simulator to play with :-O All the ESXi documentation is online, and all the relevant software has a 60-day evaluation grace period after install. You just need to work through it. Get things working in the lab, then start trying out more complicated scenarios and trying the advanced knobs later, read the installation directions; see how things work. Buying or scavenging a used server is probably easiest to do for long-term playing; look for something with 32GB of RAM, and 4 or more 2.5" SAS drives. Try to have 100GB of total disk space in a hardware RAID10 or RAID0 with 256MB or so controller writeback cache, or a SSD; the idea is to have enough space to install vCenter and operations manager and a few VMs. A 3 year old Dell 11G R610 or HP DL360 G6 likely falls into this category. Install ESXi on the server, and create 3 virtual machines that will be "Nested" ESXi servers; OS of the VMs will be ESXi. See: http://www.virtuallyghetto.com/2012/08/how-to-enable-nested-esxi-other.html If you would rather build a desktop tower for ESXi; look for a desktop motherboard with a 64-bit Intel Proc with DDR2 ECC Memory support in at least 32GB of RAM, VT-d support, and onboard Broadcom or Intel networking. Network controller and Storage controller choices are key; exotic hardware won't work Considering vCenter itself wants a minimum 12GB of RAM: in case you want to test out _both_ the vCenter virtual appliance, and the standard install on Windows.... about 32GB RAM is great. In competition against the VMware HCL, there's a "white box" HCL: http://www.vm-help.com/esx40i/esx40_whitebox_HCL.php I would look to something such as the Iomega Storcenter PX6, PX4 or Synology DS1512+ as an inexpensive shared storage solution for playing around with iSCSI-based block targets. I think the Iomegas may be the least-cost physical arrays on the official Vmware HCL, with VAAI support. You can also use a virtual machine running on the local disks of your ESXi server to present shared storage, as another VM If you run your cluster's ESXi servers as nested virtual machines, on one server. Some software options are Linux... Nexenta.... FreeNAS... Open-e. HP Lefthand.... Isilon... Falconstor....Nutanix (I would look at the first 3 primarily) Or You can also use a spare Linux machine for shared storage; I would suggest SSD for this, or when using disks: something with enough spindles in appropriate RAID level to give you at least 400 or so hundred sustained random IOPS, so you can run 3 or 4 active VMs to play with without the whole thing being appallingly slow. FreeNas / Nexenta / ZFS are also great options, 64-bit system with 16gb+ of RAM to give to Solaris. Finding a hardware configuration on which Solaris X86 will run properly out of the box can be challenging. Of course, if you have a spare Linux machine, you can also use that too, in order to play around with VMs on NFS or iSCSI. > Not sure if this list is the best place, but it is probably the only list > that I'm on that won't give me a bunch of grief about the chosen technology. > I looked at VMware's site, and there are a ton of options. I'm wondering > if anyone has some basic suggestions or experiences. > > I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm > sufficiently versed in deploying scripted ESXi (including 5.x) > installations for a specific environment, including vswitches/SAN config > (but only with NFS datastores backed by a NetApp, unfortunately, no > blockbased stores). > > -- -JH From imb at protected-networks.net Thu Feb 20 03:41:41 2014 From: imb at protected-networks.net (Michael Butler) Date: Wed, 19 Feb 2014 22:41:41 -0500 Subject: spamassassin In-Reply-To: References: <5304C3DF.8000805@viagenie.ca> <20140219190150.35f3a504.gem@rellim.com> Message-ID: <53057975.8070108@protected-networks.net> On 02/19/14 22:22, Randy Bush wrote: >> http://www.gossamer-threads.com/lists/spamassassin/users/183433 > > as blabby as nanog, and not really specific > >> body BAYES_99 eval:check_bayes('0.99', '0.999') >> body BAYES_999 eval:check_bayes('0.999', '1.00') >> score BAYES_99 0 0 3.8 3.5 >> score BAYES_999 0 0 4.0 3.7 > > and this is a replacement for both 999 and 99? You should be able to just whack it into local.cf and it'll override whatever other instances there are, Michael From mysidia at gmail.com Thu Feb 20 03:44:22 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 19 Feb 2014 21:44:22 -0600 Subject: VMware Training In-Reply-To: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 19, 2014 at 2:06 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Eugeniu Patrascu" > [snip] > My understanding of "cluster-aware filesystem" was "can be mounted at the > physical block level by multiple operating system instances with complete > safety". That seems to conflict with what you suggest, Eugeniu; am I > missing something (as I often do)? > When one of the hosts has a virtual disk file open for write access on a VMFS cluster-aware filesystem, it is locked to that particular host, and a process on a different host is denied the ability write to the file, or even open the file for read access. Another host cannot even read/write metadata about the file's directory entry. Attempts to do so, get rejected with an error. So you don't really have to worry all that much about "as long you don't access the same files", although: certainly you should not try to, either. Only the software in ESXi can access the VMFS --- there is no ability to run arbitrary applications. (Which is also, why I like NFS more than shared block storage; you can conceptually use the likes of a storage array feature such as FlexClone to make a copy-on-write clone of a file, take a storage level snapshot, and then do a granular restore of a specific VM; without having to restore the entire volume as a unit. You can't pull that off with a clustered filesystem on a block target!) Also, the VMFS filesystem is cluster aware by method of exclusion (SCSI Reservations) and separate journaling. Metadata locks are global in the VMFS cluster-aware filesystem. Only one host is allowed to write to any of the metadata -on the entire volume a- time, unless you have VAAI VMFS extensions, and your storage vendor supports the ATS (atomic test and set), resulting in a performance bottleneck. For that reason, while VMFS is cluster aware, you cannot necessarily have a large number of cluster nodes, or more than a few dozen open files, before performance degrades due to the metadata bottleneck. Another consideration is that; in the event that you have a power outage which simultaneously impacts your storage array and all your hosts: you may very well be unable to regain access to any of your files, until the specific host that had that file locked comes back up, or you wait out a ~30 to ~60 minute timeout period. > Cheers, > -- jra > -- -JH From jra at baylink.com Thu Feb 20 03:46:22 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Feb 2014 22:46:22 -0500 Subject: VMware Training In-Reply-To: References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> Message-ID: <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> Why bother with a clustering FS, then, if you cannot actually /use it/ as one? - jra On February 19, 2014 10:44:22 PM EST, Jimmy Hess wrote: >On Wed, Feb 19, 2014 at 2:06 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >> > From: "Eugeniu Patrascu" >> [snip] >> My understanding of "cluster-aware filesystem" was "can be mounted at >the >> physical block level by multiple operating system instances with >complete >> safety". That seems to conflict with what you suggest, Eugeniu; am I >> missing something (as I often do)? >> > >When one of the hosts has a virtual disk file open for write access on >a >VMFS cluster-aware filesystem, it is locked to that particular host, > and a process on a different host is denied the ability write to the >file, or even open the file for read access. > >Another host cannot even read/write metadata about the file's directory >entry. >Attempts to do so, get rejected with an error. > >So you don't really have to worry all that much about "as long you >don't >access the same files", although: certainly you should not try to, >either. > >Only the software in ESXi can access the VMFS --- there is no ability >to >run arbitrary applications. > >(Which is also, why I like NFS more than shared block storage; you can >conceptually use the likes of a storage array feature such as >FlexClone >to make a copy-on-write clone of a file, take a storage level >snapshot, >and then do a granular restore of a specific VM; without having to >restore the entire volume as a unit. > >You can't pull that off with a clustered filesystem on a block target!) > > >Also, the VMFS filesystem is cluster aware by method of exclusion >(SCSI >Reservations) and separate journaling. > >Metadata locks are global in the VMFS cluster-aware filesystem. Only >one >host is allowed to write to >any of the metadata -on the entire volume a- time, unless you have >VAAI >VMFS extensions, and your storage vendor supports the ATS (atomic >test >and set), >resulting in a performance bottleneck. > >For that reason, while VMFS is cluster aware, you cannot necessarily >have >a large number of cluster nodes, >or more than a few dozen open files, before performance degrades due >to >the metadata bottleneck. > > >Another consideration is that; in the event that you have a power >outage >which simultaneously impacts your storage array and all your hosts: >you > may very well be unable to regain access to any of your files, >until the specific host that had that file locked comes back up, or >you >wait out a ~30 to ~60 minute timeout period. > > > > >> Cheers, >> -- jra >> >-- >-JH -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From ag4ve.us at gmail.com Thu Feb 20 09:08:56 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 20 Feb 2014 04:08:56 -0500 Subject: comcast business service Message-ID: A while ago I got Comcast's business service. Semi-idle connections are get dropped (I haven't really diagnosed this - I just no that it isn't the client or server but some network in between). However the second and most obvious issue is that intermittently, the service will grind to a halt: --- 8.8.8.8 ping statistics --- 37 packets transmitted, 34 received, 8% packet loss, time 36263ms rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 After a modem reboot, it goes normal: --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms This seems to happen about once or twice a day. I can't attribute it to any type of traffic or number of connections. All of the rest of the network equipment is the same and the behavior persists when a computer is plugged directly into the modem. I called Comcast and they said they didn't see anything even when I was experiencing ridiculous ping times. I tend to think it's an issue with the 'modem' but I'm not sure what the issue might be or how to reproduce it when asked to if I tell them to look at it. From me at geordish.org Thu Feb 20 09:50:22 2014 From: me at geordish.org (Dave Bell) Date: Thu, 20 Feb 2014 09:50:22 +0000 Subject: VMware Training In-Reply-To: <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> Message-ID: It means your VMs can run on any host and access the files it requires. If this was not the case then you could not tolerate a hardware failure and expect your VMs to survive. It also means you can do things like evacuate a host and take it down for maintenance. Of course you could build your application in a way that can tolerate the failure of a host, and just use local storage for your guests. It really depends on what you are trying to achieve though. On 20 February 2014 03:46, Jay Ashworth wrote: > Why bother with a clustering FS, then, if you cannot actually /use it/ as > one? > - jra > > On February 19, 2014 10:44:22 PM EST, Jimmy Hess > wrote: > >On Wed, Feb 19, 2014 at 2:06 PM, Jay Ashworth wrote: > > > >> ----- Original Message ----- > >> > From: "Eugeniu Patrascu" > >> [snip] > >> My understanding of "cluster-aware filesystem" was "can be mounted at > >the > >> physical block level by multiple operating system instances with > >complete > >> safety". That seems to conflict with what you suggest, Eugeniu; am I > >> missing something (as I often do)? > >> > > > >When one of the hosts has a virtual disk file open for write access on > >a > >VMFS cluster-aware filesystem, it is locked to that particular host, > > and a process on a different host is denied the ability write to the > >file, or even open the file for read access. > > > >Another host cannot even read/write metadata about the file's directory > >entry. > >Attempts to do so, get rejected with an error. > > > >So you don't really have to worry all that much about "as long you > >don't > >access the same files", although: certainly you should not try to, > >either. > > > >Only the software in ESXi can access the VMFS --- there is no ability > >to > >run arbitrary applications. > > > >(Which is also, why I like NFS more than shared block storage; you can > >conceptually use the likes of a storage array feature such as > >FlexClone > >to make a copy-on-write clone of a file, take a storage level > >snapshot, > >and then do a granular restore of a specific VM; without having to > >restore the entire volume as a unit. > > > >You can't pull that off with a clustered filesystem on a block target!) > > > > > >Also, the VMFS filesystem is cluster aware by method of exclusion > >(SCSI > >Reservations) and separate journaling. > > > >Metadata locks are global in the VMFS cluster-aware filesystem. Only > >one > >host is allowed to write to > >any of the metadata -on the entire volume a- time, unless you have > >VAAI > >VMFS extensions, and your storage vendor supports the ATS (atomic > >test > >and set), > >resulting in a performance bottleneck. > > > >For that reason, while VMFS is cluster aware, you cannot necessarily > >have > >a large number of cluster nodes, > >or more than a few dozen open files, before performance degrades due > >to > >the metadata bottleneck. > > > > > >Another consideration is that; in the event that you have a power > >outage > >which simultaneously impacts your storage array and all your hosts: > >you > > may very well be unable to regain access to any of your files, > >until the specific host that had that file locked comes back up, or > >you > >wait out a ~30 to ~60 minute timeout period. > > > > > > > > > >> Cheers, > >> -- jra > >> > >-- > >-JH > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From eugen at imacandi.net Thu Feb 20 11:43:17 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 20 Feb 2014 13:43:17 +0200 Subject: VMware Training In-Reply-To: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Eugeniu Patrascu" > > > If you want block storage, just export an iSCSI device to the ESXi > machines > > (tgtadm on RedHat is all you need and a few gigs of free space). VMFS is > > cluster aware so you can export the same volume to independent ESXi hosts > > and as long you don't access the same files, you're good to go. > > My understanding of "cluster-aware filesystem" was "can be mounted at the > physical block level by multiple operating system instances with complete > safety". That seems to conflict with what you suggest, Eugeniu; am I > missing something (as I often do)? > > What you are saying is true and from VMware's point of view, an ISCSI volume is a physical disk. And you can mount the same ISCSI disk on many VMware hosts. Just write into different directories on the disk. Am I missing something in your question ? Eugeniu > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > > From simon.perreault at viagenie.ca Thu Feb 20 13:34:39 2014 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Thu, 20 Feb 2014 08:34:39 -0500 Subject: spamassassin In-Reply-To: References: <5304C3DF.8000805@viagenie.ca> Message-ID: <5306046F.9000902@viagenie.ca> Le 2014-02-19 21:48, Randy Bush a ?crit : > as the fix is not yet out, would be cool if someone with more fu than i > posted a recipe to hack for the moment. The fix is out now! :D Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adam.vitkovsky at swan.sk Thu Feb 20 14:37:29 2014 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 20 Feb 2014 15:37:29 +0100 Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: <5303C8F3.4000304@direcpath.com> References: <5303B047.5020701@cox.net> <5303C8F3.4000304@direcpath.com> Message-ID: <056201cf2e49$48651c70$d92f5550$@swan.sk> > Actually, it would be nice if someone who writes security software > like NOD32 or Malwarebytes, or spybot, adaware, etc, would > integrate it into their test suite. Then you get the thousands of > users from them added to the results. I have just sent an email to ESET promoting participation on the BCP38 initiative by incorporating spoofer projects program in their program suite. If there's more of us maybe we can make a change. adam -----Original Message----- From: Robert Drake [mailto:rdrake at direcpath.com] Sent: Tuesday, February 18, 2014 9:56 PM To: nanog at nanog.org Subject: Re: "Everyone should be deploying BCP 38! Wait, they are ...." On 2/18/2014 2:19 PM, James Milko wrote: > Is using data from a self-selected group even meaningful when > extrapolated? It's been a while since Stats in college, and it's very > likely the guys from MIT know more than I do, but one of the big > things they pushed was random sampling. > > JM > > Isn't it probable that people who know enough to download the spoofer projects program and run it might also be in position to fix things when it's broken, or they may just be testing their own networks which they've already secured, just to verify they got it right. I may put it on my laptop and start testing random places like Starbucks, my moms house, conventions and other things, but if I'm running it from my home machine it's just to get the gold "I did this" star. So yeah, data from the project is probably meaningless unless someone uses it as a worm payload and checks 50,000 computers randomly (of course I don't advise this. I just wish there was a way to really push this to be run by everyone in the world for a week) Maybe with enough hype we could get CNN to advise people to download it. Actually, it would be nice if someone who writes security software like NOD32 or Malwarebytes, or spybot, adaware, etc, would integrate it into their test suite. Then you get the thousands of users from them added to the results. From symack at gmail.com Thu Feb 20 15:08:35 2014 From: symack at gmail.com (Nick Cameo) Date: Thu, 20 Feb 2014 10:08:35 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets Message-ID: Hello Everyone, According to mtr command we are consistently seeing level3_bx4-montrealak.net dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get this resolved are greatly appreciated. HOST: victoria Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.2.1 0.0% 10 0.5 0.8 0.4 1.6 0.5 2.|-- lns2-montrealak_lo0_LNS.n 0.0% 10 6.7 7.6 6.7 8.8 0.7 3.|-- agg1-montrealak_GE0-2-2_1 0.0% 10 6.4 6.3 5.4 7.6 0.6 4.|-- bx4-montrealak_so-0-0-0.n 0.0% 10 6.0 5.8 4.9 7.0 0.7 5.|-- level3_bx4-montrealak.net 50.0% 10 6.5 6.7 5.7 7.9 0.8 6.|-- ae-11-11.car1.Montreal2.L 0.0% 10 92.2 91.7 91.0 92.8 0.7 7.|-- ae-5-5.ebr2.NewYork1.Leve 0.0% 10 90.9 92.0 90.9 92.7 0.6 Kind Regards, Nick. From symack at gmail.com Thu Feb 20 15:20:00 2014 From: symack at gmail.com (Nick Cameo) Date: Thu, 20 Feb 2014 10:20:00 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: References: Message-ID: | Since you dont see packet loss on the subsequent hops, this is likely just ICMP rate limiting on the control plane. MTR | sends quite a bit of ICMP so this is very common when using MTR. Not a "possible" reason for the degradation of voip from us to our service provider? Is there a more accurate test that will render more explanation? Thanks for the prompt Chris. From jared at puck.nether.net Thu Feb 20 15:27:37 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Feb 2014 10:27:37 -0500 Subject: comcast business service In-Reply-To: References: Message-ID: On Feb 20, 2014, at 4:08 AM, shawn wilson wrote: > A while ago I got Comcast's business service. Semi-idle connections > are get dropped (I haven't really diagnosed this - I just no that it > isn't the client or server but some network in between). However the > second and most obvious issue is that intermittently, the service will > grind to a halt: > --- 8.8.8.8 ping statistics --- > 37 packets transmitted, 34 received, 8% packet loss, time 36263ms > rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 > > After a modem reboot, it goes normal: > --- 8.8.8.8 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3003ms > rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms > > This seems to happen about once or twice a day. I can't attribute it > to any type of traffic or number of connections. All of the rest of > the network equipment is the same and the behavior persists when a > computer is plugged directly into the modem. I called Comcast and they > said they didn't see anything even when I was experiencing ridiculous > ping times. I tend to think it's an issue with the 'modem' but I'm not > sure what the issue might be or how to reproduce it when asked to if I > tell them to look at it. Is this on their DOCSIS service? I've seen the F connector on the back of the CM introduce noise to the local segment and cause troubles. If so, you need to have them dispatch and swap the CM with one that doesn't have this issue. - Jared From geier at geier.ne.tz Thu Feb 20 16:11:37 2014 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 20 Feb 2014 19:11:37 +0300 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: References: Message-ID: <53062939.9000809@geier.ne.tz> On 2/20/2014 6:08 PM, Nick Cameo wrote: > According to mtr command we are consistently seeing > level3_bx4-montrealak.net > dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get > this resolved are greatly appreciated. It's dropping packets _to_ and/or _from_ it. Seem it's got the priorities well adjusted and does not drop packets being _forwarded_ (see hops 6 and 7). first $search_engine hit for me was https://library.linode.com/linux-tools/mtr#sph_icmp-rate-limiting Frank From niels=nanog at bakker.net Thu Feb 20 16:14:45 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 20 Feb 2014 17:14:45 +0100 Subject: NTP DRDos Blog post In-Reply-To: References: Message-ID: <20140220161445.GJ67472@burnout.tpb.net> * stenn at ntp.org (Harlan Stenn) [Thu 20 Feb 2014, 00:38 CET]: >I'd love to hear any feedback about the post. Don't invent new terms like DrDos. -- Niels. From sf at lists.esoteric.ca Thu Feb 20 16:16:22 2014 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 20 Feb 2014 11:16:22 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: References: Message-ID: <53062A56.2010309@lists.esoteric.ca> There are reports of problems in Montreal with several other providers over the last several days. These seem to coincide with the Olympics live broadcasts, particularly during the hockey broadcasts. -- Stephen On 2014-02-20 10:08 AM, Nick Cameo wrote: > Hello Everyone, > > According to mtr command we are consistently seeing > level3_bx4-montrealak.net > dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get > this resolved are greatly appreciated. > > > HOST: victoria Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.2.1 0.0% 10 0.5 0.8 0.4 1.6 0.5 > 2.|-- lns2-montrealak_lo0_LNS.n 0.0% 10 6.7 7.6 6.7 8.8 0.7 > 3.|-- agg1-montrealak_GE0-2-2_1 0.0% 10 6.4 6.3 5.4 7.6 0.6 > 4.|-- bx4-montrealak_so-0-0-0.n 0.0% 10 6.0 5.8 4.9 7.0 0.7 > 5.|-- level3_bx4-montrealak.net 50.0% 10 6.5 6.7 5.7 7.9 0.8 > 6.|-- ae-11-11.car1.Montreal2.L 0.0% 10 92.2 91.7 91.0 92.8 0.7 > 7.|-- ae-5-5.ebr2.NewYork1.Leve 0.0% 10 90.9 92.0 90.9 92.7 0.6 > > > Kind Regards, > > Nick. > From rdobbins at arbor.net Thu Feb 20 16:17:08 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 20 Feb 2014 16:17:08 +0000 Subject: NTP DRDos Blog post In-Reply-To: <20140220161445.GJ67472@burnout.tpb.net> References: <20140220161445.GJ67472@burnout.tpb.net> Message-ID: <4CE63F87-F7F2-4C36-8BEE-171067E728F6@arbor.net> On Feb 20, 2014, at 11:14 PM, Niels Bakker wrote: > Don't invent new terms like DrDos. +1 ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From brak at gameservers.com Thu Feb 20 16:23:58 2014 From: brak at gameservers.com (Brian Rak) Date: Thu, 20 Feb 2014 11:23:58 -0500 Subject: NTP DRDos Blog post In-Reply-To: <20140220161445.GJ67472@burnout.tpb.net> References: <20140220161445.GJ67472@burnout.tpb.net> Message-ID: <53062C1E.1070402@gameservers.com> That's not a new term. http://en.wikipedia.org/wiki/DRDOS DRDoS, a type of network attack named Distributed Reflection Denial of Service. http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack On 2/20/2014 11:14 AM, Niels Bakker wrote: > * stenn at ntp.org (Harlan Stenn) [Thu 20 Feb 2014, 00:38 CET]: >> I'd love to hear any feedback about the post. > > Don't invent new terms like DrDos. > > > -- Niels. > From rdobbins at arbor.net Thu Feb 20 16:34:30 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 20 Feb 2014 16:34:30 +0000 Subject: NTP DRDos Blog post In-Reply-To: <53062C1E.1070402@gameservers.com> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> Message-ID: <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> On Feb 20, 2014, at 11:23 PM, Brian Rak wrote: > That's not a new term. It isn't used by folks involved in operational security. It's a marketing term. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jlewis at lewis.org Thu Feb 20 16:43:36 2014 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 20 Feb 2014 11:43:36 -0500 (EST) Subject: NTP DRDos Blog post In-Reply-To: <53062C1E.1070402@gameservers.com> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> Message-ID: On Thu, 20 Feb 2014, Brian Rak wrote: > That's not a new term. > > http://en.wikipedia.org/wiki/DRDOS > DRDoS, a type of network attack named Distributed Reflection Denial of > Service. > http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack Or Digital Research Disk Operating System...if you're old enough. Who knew DRDOS would become popular [again]? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jayfar at jayfar.com Thu Feb 20 16:46:47 2014 From: jayfar at jayfar.com (Jay Farrell) Date: Thu, 20 Feb 2014 11:46:47 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: References: Message-ID: A careful reading of the following fixes this issue every time it occurs. I guarantee it. https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf On Thu, Feb 20, 2014 at 10:08 AM, Nick Cameo wrote: > Hello Everyone, > > According to mtr command we are consistently seeing > level3_bx4-montrealak.net > dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get > this resolved are greatly appreciated. > > > HOST: victoria Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.2.1 0.0% 10 0.5 0.8 0.4 1.6 0.5 > 2.|-- lns2-montrealak_lo0_LNS.n 0.0% 10 6.7 7.6 6.7 8.8 0.7 > 3.|-- agg1-montrealak_GE0-2-2_1 0.0% 10 6.4 6.3 5.4 7.6 0.6 > 4.|-- bx4-montrealak_so-0-0-0.n 0.0% 10 6.0 5.8 4.9 7.0 0.7 > 5.|-- level3_bx4-montrealak.net 50.0% 10 6.5 6.7 5.7 7.9 0.8 > 6.|-- ae-11-11.car1.Montreal2.L 0.0% 10 92.2 91.7 91.0 92.8 0.7 > 7.|-- ae-5-5.ebr2.NewYork1.Leve 0.0% 10 90.9 92.0 90.9 92.7 0.6 > > > Kind Regards, > > Nick. From deleskie at gmail.com Thu Feb 20 16:48:05 2014 From: deleskie at gmail.com (deleskie at gmail.com) Date: Thu, 20 Feb 2014 12:48:05 -0400 Subject: NTP DRDos Blog post In-Reply-To: <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> Message-ID: <20140220164805.5562513.67852.11191@gmail.com> From jared at puck.nether.net Thu Feb 20 17:17:51 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Feb 2014 12:17:51 -0500 Subject: NTP DRDos Blog post In-Reply-To: <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> Message-ID: On Feb 20, 2014, at 11:34 AM, Dobbins, Roland wrote: > > On Feb 20, 2014, at 11:23 PM, Brian Rak wrote: > >> That's not a new term. > > It isn't used by folks involved in operational security. It's a marketing term. > I'll split the difference, folks in operational security dislike the term as they feel it's inaccurate. They tend to think it's marketing vs operational related. Reflection attacks are considered a sub-type of DoS/DDoS and do not require a new term. It's the same problem folks have with absolute terms like "Unlimited Data" with the asterisk. Can I direct the knife-fights about that part off-list? :) (and preferably exclude me, i get enough email). - jared From refresh.lsong at gmail.com Thu Feb 20 08:14:59 2014 From: refresh.lsong at gmail.com (Song Li) Date: Thu, 20 Feb 2014 16:14:59 +0800 Subject: question about AS relationship Message-ID: <5305B983.1080406@gmail.com> Hi everyone, I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that? Thanks! -- Sky Li From pgreen at seznam.cz Thu Feb 20 13:57:53 2014 From: pgreen at seznam.cz (Pavel Zeleny) Date: Thu, 20 Feb 2014 13:57:53 +0000 (UTC) Subject: random dns queries with random sources References: <5304201A.3040508@ttec.com> <5305248A.4030406@necom830.hpcl.titech.ac.jp> Message-ID: Masataka Ohta necom830.hpcl.titech.ac.jp> writes: > > Joe Maimon wrote: > > > What is the purpose of this? ... > > Masataka Ohta > Hi guys, for a second, have you any clue how to block this traffic on DNS server side? As our company operates recursive resolvers for our customers, we can see this weird traffic concentrated in our logs. It started Feb 3 about 16:30 (GMT/UTC+1). Very large amount of DNS A queries are sent from source IP addresses of our customers, and they always looks like [randomjunk].SLD.com. We have seen 143 this SLD's so far, and we had to block it manually one by one. We suspect some kind of botnet, because attack wave with new SLD's starts at the same time, coming from broad range of valid non-spoofed source IP addresses. Content of UDP packets belonging to this traffic doesn't seem to have any identical pattern. Any ideas are highly appreciated. Thank you! Pavel Zeleny From ben.russell at countryfinancial.com Thu Feb 20 14:28:50 2014 From: ben.russell at countryfinancial.com (Russell, Ben) Date: Thu, 20 Feb 2014 08:28:50 -0600 Subject: prefix advertisement Message-ID: <4A638950B27347428796CE85845BE09D238888C433@C1MBC130.corp.alliance.lan> Can someone from Comcast BGP team contact me off list? I am seeing AS 33491 advertising one of our prefixes. Thanks -Ben From antoine.meillet at orange.com Thu Feb 20 16:29:55 2014 From: antoine.meillet at orange.com (antoine.meillet at orange.com) Date: Thu, 20 Feb 2014 16:29:55 +0000 Subject: NTP DRDos Blog post In-Reply-To: <53062C1E.1070402@gameservers.com> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> Message-ID: <25863_1392913796_53062D84_25863_328_1_3A0B5478A6C3E74C9F955D83416723174DD03D@OPEXCLILM23.corporate.adroot.infra.ftgroup> Yes, it was also used here https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 But still, it's just a DDoS. -----Message d'origine----- De?: Brian Rak [mailto:brak at gameservers.com] Envoy??: jeudi 20 f?vrier 2014 17:24 ??: nanog at nanog.org Objet?: Re: NTP DRDos Blog post That's not a new term. http://en.wikipedia.org/wiki/DRDOS DRDoS, a type of network attack named Distributed Reflection Denial of Service. http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack On 2/20/2014 11:14 AM, Niels Bakker wrote: > * stenn at ntp.org (Harlan Stenn) [Thu 20 Feb 2014, 00:38 CET]: >> I'd love to hear any feedback about the post. > > Don't invent new terms like DrDos. > > > -- Niels. > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From morrowc.lists at gmail.com Thu Feb 20 18:09:35 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 20 Feb 2014 13:09:35 -0500 Subject: question about AS relationship In-Reply-To: <5305B983.1080406@gmail.com> References: <5305B983.1080406@gmail.com> Message-ID: On Thu, Feb 20, 2014 at 3:14 AM, Song Li wrote: > Hi everyone, > > I have one simple question: as for AS relationship, should customer tell its > provider the AS# of its own customers, or the provider have the right to > require its customers to do that? in an ideal world the ISP is filtering prefixes from their customer, which means that the customer has to disclose downstream information. so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented. don't turn up bgp customers without filtering, that kills kittens. -chris From jra at baylink.com Thu Feb 20 18:12:22 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Feb 2014 13:12:22 -0500 (EST) Subject: "Everyone should be deploying BCP 38! Wait, they are ...." In-Reply-To: <056201cf2e49$48651c70$d92f5550$@swan.sk> Message-ID: <25578152.9492.1392919942236.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Adam Vitkovsky" > > Actually, it would be nice if someone who writes security software > > like NOD32 or Malwarebytes, or spybot, adaware, etc, would > > integrate it into their test suite. Then you get the thousands of > > users from them added to the results. > > I have just sent an email to ESET promoting participation on the BCP38 > initiative by incorporating spoofer projects program in their program > suite. Absolutely. I've queried the PI on the ex-MIT ANA spoofing measuring project, prepatory to inquiring of the other projects mentioned above; we should all be pulling in the same direction, measuring the same things, with the same infrastructure if possible. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Thu Feb 20 18:16:23 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Feb 2014 13:16:23 -0500 (EST) Subject: VMware Training In-Reply-To: Message-ID: <1005005.9494.1392920183283.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eugeniu Patrascu" > On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth > wrote: > > > ----- Original Message ----- > > My understanding of "cluster-aware filesystem" was "can be mounted at the > > physical block level by multiple operating system instances with complete > > safety". That seems to conflict with what you suggest, Eugeniu; am I > > missing something (as I often do)? > > What you are saying is true and from VMware's point of view, an ISCSI > volume is a physical disk. > And you can mount the same ISCSI disk on many VMware hosts. Just write > into different directories on the disk. > > Am I missing something in your question ? I guess. You and Jimmy seem to be asserting that, in fact, you *cannot* mount a given physical volume, with a clustering FS in its partition, onto multiple running OS images at the same time... at which point, why bother using a clustering FS? The point of clustering FSs (like Gluster, say), as I understood it, was that they could be mounted by multiple machines simultaneously: that there was no presumed state between the physical blocks and the FS driver inside each OS, which would cause things to Fail Spectacularly if more than one machine was simultaneously using them in realtime. You and Jimmy seem to be suggesting that multiple OSs need to be semaphored. One of three understandings here is wrong. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From rdobbins at arbor.net Thu Feb 20 18:28:58 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 20 Feb 2014 18:28:58 +0000 Subject: NTP DRDos Blog post In-Reply-To: <25863_1392913796_53062D84_25863_328_1_3A0B5478A6C3E74C9F955D83416723174DD03D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <25863_1392913796_53062D84_25863_328_1_3A0B5478A6C3E74C9F955D83416723174DD03D@OPEXCLILM23.corporate.adroot.infra.ftgroup> Message-ID: On Feb 20, 2014, at 11:29 PM, wrote: > Yes, it was also used here https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 That's still meaningless. The term of art is 'reflection/amplification attack', as in 'ntp reflection/amplification attack' or 'DNS reflection/amplification attack'. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jra at baylink.com Thu Feb 20 18:29:32 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Feb 2014 13:29:32 -0500 (EST) Subject: NTP DRDos Blog post In-Reply-To: <4CE63F87-F7F2-4C36-8BEE-171067E728F6@arbor.net> Message-ID: <20824318.9504.1392920972508.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Roland Dobbins" > On Feb 20, 2014, at 11:14 PM, Niels Bakker > wrote: > > > Don't invent new terms like DrDos. > > +1 What? Digital Research's MS-DOS clone is attacking things? Cheers, -- jr ':-)' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From symack at gmail.com Thu Feb 20 18:35:30 2014 From: symack at gmail.com (Nick Cameo) Date: Thu, 20 Feb 2014 13:35:30 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: References: Message-ID: Makes even more sense when you're a CS student working on getting your PPL ;) N. From eugen at imacandi.net Thu Feb 20 18:47:55 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 20 Feb 2014 20:47:55 +0200 Subject: VMware Training In-Reply-To: <1005005.9494.1392920183283.JavaMail.root@benjamin.baylink.com> References: <1005005.9494.1392920183283.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 20, 2014 at 8:16 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Eugeniu Patrascu" > > > On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth > > wrote: > > > > > ----- Original Message ----- > > > My understanding of "cluster-aware filesystem" was "can be mounted at > the > > > physical block level by multiple operating system instances with > complete > > > safety". That seems to conflict with what you suggest, Eugeniu; am I > > > missing something (as I often do)? > > > > What you are saying is true and from VMware's point of view, an ISCSI > > volume is a physical disk. > > And you can mount the same ISCSI disk on many VMware hosts. Just write > > into different directories on the disk. > > > > Am I missing something in your question ? > > I guess. You and Jimmy seem to be asserting that, in fact, you *cannot* > mount a given physical volume, with a clustering FS in its partition, > onto multiple running OS images at the same time... at which point, why > bother using a clustering FS? > > OK, let me give it another try: You have a machine that exports an ISCSI disk (such as a SAN or a plain Linux box). You have 2-3-5-X machines (hosts) that run ESXi. You can mount that ISCSI disk on all ESXi hosts at the same time and use it as a datastore for VMs and run the VMs from there. What I said (and maybe this caused some confusion) is that you should not access the same files from different hosts at the same time, but you can run VM1 on host1, VM2 on host2 and so on without any issues from the same ISCSI target. > The point of clustering FSs (like Gluster, say), as I understood it, > was that they could be mounted by multiple machines simultaneously: that > there was no presumed state between the physical blocks and the FS driver > inside each OS, which would cause things to Fail Spectacularly if more > than one machine was simultaneously using them in realtime. > > In the scenario described above and how VMware ESXi works in general, only VMware accesses the filesystem (the filesystem is called VMFS). The hard drives for the virtual machines are actually represented by files on the VMFS and so the virtual machines does not touch the filesystem on the ESXi hosts directly. > You and Jimmy seem to be suggesting that multiple OSs need to be > semaphored. > > He says that multiple ESXi hosts need to be semaphored when they update the metadata on the VMFS. I don't have any opinion on this as no matter how much I abused VMware, the filesystem stayed intact. > One of three understandings here is wrong. :-) > > I hope I cleared up some of the confusion. Eugeniu From mysidia at gmail.com Thu Feb 20 18:48:50 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Feb 2014 12:48:50 -0600 Subject: VMware Training In-Reply-To: <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> Message-ID: On Wed, Feb 19, 2014 at 9:46 PM, Jay Ashworth wrote: > Why bother with a clustering FS, then, if you cannot actually /use it/ as > one? > It is used as one. It is also a lot more convenient to have a shared filesystem, than a distributed volume manager. You could think of VMDK files on a VMFS volume as their alternative to a Clustered Linux LVM. Just because you have some sort of clustered volume manager, doesn't make your guest operating systems cluster-aware. With VMFS... if two guest operating systems try to open the same disk, hypothetically, the most likely reason would be that there is a split brain in your HA cluster, and two hosts are trying to startup the same VM. The locking restrictions are for your own protection. If the filesystem inside your virtual disks is not a clustered filesystem; two instances of a VM simultaneously mounting the same NTFS volume and writing some things, is an absolute disaster. Under normal circumstances, two applications should never be writing to the same file. This is true on clustered filesystems. This is true when running multiple applications on a single computer. There is such a thing as 'Shared disk mode': if your block target is Fibre Channel, and you are using Microsoft Cluster Services in VMs, but an extra virtual SCSI adapter on a VM in shared mode, is something that you have to explicitly configure (It's not the default). There are many good things to be said about having a single-purpose filesystem, which can be placed on a shared storage device --- which multiple hosts can mount simultaneously, and view the same file/folder structure, and touch resources corresponding to which applications are running on that node... That does not require cluster votes and majority nodeset Quorums to keep the cluster from totally going out, and it does not need questionable techniques such as STONITH ("Shoot the other node in the head") as a fencing strategy, for providing exclusive access to resources. Different hosts can access files corresponding to resources running on that host, and HA is able to fail virtual disks over, so the Highly-specialized filesystem achieves all the objectives, that it needs to be a clustered filesystem to solve. > - jra > -- -JH From shoop at iwiring.net Thu Feb 20 18:55:39 2014 From: shoop at iwiring.net (Dan Shoop) Date: Thu, 20 Feb 2014 13:55:39 -0500 Subject: VMware Training In-Reply-To: <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> Message-ID: <5B7F1288-C12D-4447-94A6-5E72F3FE4B50@iwiring.net> [See below] On Feb 19, 2014, at 10:46 PM, Jay Ashworth wrote: > Why bother with a clustering FS, then, if you cannot actually /use it/ as one? > - jra > > On February 19, 2014 10:44:22 PM EST, Jimmy Hess wrote: >> On Wed, Feb 19, 2014 at 2:06 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Eugeniu Patrascu" >>> [snip] >>> My understanding of "cluster-aware filesystem" was "can be mounted at >> the >>> physical block level by multiple operating system instances with >> complete >>> safety". That seems to conflict with what you suggest, Eugeniu; am I >>> missing something (as I often do)? >>> >> >> When one of the hosts has a virtual disk file open for write access on >> a >> VMFS cluster-aware filesystem, it is locked to that particular host, >> and a process on a different host is denied the ability write to the >> file, or even open the file for read access. Ghods how I miss real tightly coupled clustering, shared hierarchical storage and true clustered filesystems like in VMS. Here?s a 35 year old OS that still is better than anything we have today. Secure, granular prigs, file versioning, multiple simultaneous cluster interconnect physical layers, POSIX compliance, heavy distributed networking and strong system services built in. When people tell me about clustering today and then add these caveats about how clustered files aren?t actually sharable or that you can?t have complete orthogonality. I guess I?m now old. -d ----- Dan Shoop shoop at iwiring.net 1-646-402-5293 (GoogleVoice) From bill at herrin.us Thu Feb 20 18:58:06 2014 From: bill at herrin.us (William Herrin) Date: Thu, 20 Feb 2014 13:58:06 -0500 Subject: question about AS relationship In-Reply-To: <5305B983.1080406@gmail.com> References: <5305B983.1080406@gmail.com> Message-ID: On Thu, Feb 20, 2014 at 3:14 AM, Song Li wrote: > I have one simple question: as for AS relationship, should customer tell its > provider the AS# of its own customers, or the provider have the right to > require its customers to do that? Um... you DO tell your provider the AS numbers of your customers... in the BGP route announcement you send them. It's not a question of rights or requirements. You already do it. Because that's how the technology works. As Chris noted, telling your provider out-of-band before sending the same information via BGP is also a very good idea which enhances the security of the whole doggone Internet. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From DStaal at usa.net Thu Feb 20 18:59:52 2014 From: DStaal at usa.net (Daniel Staal) Date: Thu, 20 Feb 2014 13:59:52 -0500 Subject: spamassassin In-Reply-To: References: <5304C3DF.8000805@viagenie.ca> <20140219190150.35f3a504.gem@rellim.com> Message-ID: <10967671F9548B4D5F29CAC7@[192.168.1.50]> --As of February 20, 2014 11:22:34 AM +0800, Randy Bush is alleged to have said: >> http://www.gossamer-threads.com/lists/spamassassin/users/183433 > > as blabby as nanog, and not really specific > >> body BAYES_99 eval:check_bayes('0.99', '0.999') >> body BAYES_999 eval:check_bayes('0.999', '1.00') >> score BAYES_99 0 0 3.8 3.5 >> score BAYES_999 0 0 4.0 3.7 > > and this is a replacement for both 999 and 99? --As for the rest, it is mine. It's a redefinition of both, yes. It was partly given in the original thread as a help to understand what was happening - and it was listed as a *temporary* fix, until the rule has been stabilized. Discussion on both of these rules is ongoing at the moment, and I wouldn't advise the above fix unless you are following it. It's likely that it will double-score some of your spam, or drastically change the meanings of the rules from what is shipped, if not now than soon. Putting the 'score' lines in your local.cf or user_prefs should be fine, but I'd avoid the definition lines. (`/etc/mail/spmassassin/local.cf` is the usual main editable config file for spamassissin, and `~/.spamassassin/user_prefs` is per-user configs, if you have that.) The correct score has been pushed, as Simon Perreault mentioned. Taking out anything you've done and running sa-update should get you a working ruleset. (If you've increased the score of either one in the normal fashions - using local.cf or user_prefs - that should be fine.) Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From jw at nuclearfallout.net Thu Feb 20 19:37:57 2014 From: jw at nuclearfallout.net (John) Date: Thu, 20 Feb 2014 11:37:57 -0800 Subject: NTP DRDos Blog post In-Reply-To: References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> Message-ID: <53065995.2010306@nuclearfallout.net> On 2/20/2014 9:17 AM, Jared Mauch wrote: > I'll split the difference, folks in operational security dislike the term as they > feel it's inaccurate. They tend to think it's marketing vs operational related. > > Reflection attacks are considered a sub-type of DoS/DDoS and do not require a new > term. It's the same problem folks have with absolute terms like "Unlimited Data" > with the asterisk. > > Can I direct the knife-fights about that part off-list? :) (and preferably exclude me, > i get enough email). This is not a new term (certainly >12yo) and one that I see as useful, just as it is useful to differentiate between a DoS and a DDoS. That extra "D" tells you that it's "distributed". Add an "R" and now it's "reflected" -- an important difference. If it's seen as being recently co-opted and misused by marketing people, then that's a shame. But its practicality trumps that in my eyes. And I am definitely on the operational security side here. I do generally prefer "X reflection/amplification attack", as Roland suggested, as it is more specific. -John From rdobbins at arbor.net Thu Feb 20 19:43:40 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 20 Feb 2014 19:43:40 +0000 Subject: NTP DRDos Blog post In-Reply-To: <53065995.2010306@nuclearfallout.net> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> <53065995.2010306@nuclearfallout.net> Message-ID: <54862F77-A2CC-4F54-A261-9195133FDB50@arbor.net> On Feb 21, 2014, at 2:37 AM, John wrote: > This is not a new term (certainly >12yo) Actually, it's much more recent than that (in this context; as others have mentioned, DR-DOS was the acronym for Digital Research's MS-DOS clone). But I'm going to stop posting about this, now, as Jared suggested. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From shoop at iwiring.net Thu Feb 20 19:49:25 2014 From: shoop at iwiring.net (Dan Shoop) Date: Thu, 20 Feb 2014 14:49:25 -0500 Subject: VMware Training In-Reply-To: References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> Message-ID: <64B7A262-4EDD-46A6-B2E2-30814897FA5C@iwiring.net> On Feb 20, 2014, at 1:48 PM, Jimmy Hess wrote: > The locking restrictions are for your own protection. If the filesystem > inside your virtual disks is not a clustered filesystem; > two instances of a VM simultaneously mounting the same NTFS volume and > writing some things, is an absolute disaster. > > > Under normal circumstances, two applications should never be writing to > the same file. This is true on clustered filesystems. > This is true when running multiple applications on a single computer. Why should "two applications should never be writing to the same file"? In a real clustered *file*system this is exactly what you want. The same logical volume mounted across host cluster members, perhaps geodistantly located, each having access at the record level to the data. This permits HA and for the application to be distributed across cluster nodes. If a host node is lost then the application stays running. If the physical volume is unavailable then logically shadowing the volume across node members or storage controllers / SANs permits fault tolerance. You don?t need to ?fail disks over? (really logical volumes) as they are resilient from the start, they just don?t fail. When the shadow members return they replay journals or resilver if the journals are lost. I?d note that this can be accomplished just so long as you have a common disk format across the OS nodes. These problems were all resolved 40 years ago in mainframe and supermini systems. They?re not new. VMware has been slowly reinventing ? more accurately rediscovering ? well known HA techniques as it?s trying to mature. And it still has a lot of catching up to do. It?s the same tale that microcomputers have been doing for decades as they?ve come into use as servers. However I?m not sure what all of this has to do with network operations. ;) -d ----- Dan Shoop shoop at iwiring.net 1-646-402-5293 (GoogleVoice) From jw at nuclearfallout.net Thu Feb 20 19:51:49 2014 From: jw at nuclearfallout.net (John) Date: Thu, 20 Feb 2014 11:51:49 -0800 Subject: NTP DRDos Blog post In-Reply-To: <54862F77-A2CC-4F54-A261-9195133FDB50@arbor.net> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> <53065995.2010306@nuclearfallout.net> <54862F77-A2CC-4F54-A261-9195133FDB50@arbor.net> Message-ID: <53065CD5.7060007@nuclearfallout.net> On 2/20/2014 11:43 AM, Dobbins, Roland wrote: > Actually, it's much more recent than that (in this context; as others have mentioned, DR-DOS was the acronym for Digital Research's MS-DOS clone). I didn't just pluck that 12y term out of the air. I know how much Gibson is hated in some circles, but he used it in 2002: http://homes.cs.washington.edu/~arvind/cs425/doc/drdos.pdf. I read that in 2002, did other research about it in 2002, saw reflected attacks in 2002. Yes, I used DRDOS, too. -John From shoop at iwiring.net Thu Feb 20 19:59:49 2014 From: shoop at iwiring.net (Dan Shoop) Date: Thu, 20 Feb 2014 14:59:49 -0500 Subject: NTP DRDos Blog post In-Reply-To: References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> Message-ID: <423FC1DC-CE0D-4085-88E9-418AE5B6E1A5@iwiring.net> On Feb 20, 2014, at 11:43 AM, Jon Lewis wrote: > On Thu, 20 Feb 2014, Brian Rak wrote: > >> That's not a new term. >> >> http://en.wikipedia.org/wiki/DRDOS >> DRDoS, a type of network attack named Distributed Reflection Denial of Service. >> http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack > > Or Digital Research Disk Operating System...if you're old enough. > Who knew DRDOS would become popular [again]? I had wondered what the problem was, older than age, with anyone trying to run DRDOS. It should fit in the memory and cpu footprint of a modern toaster. -d ----- Dan Shoop shoop at iwiring.net 1-646-402-5293 (GoogleVoice) From rdobbins at arbor.net Thu Feb 20 20:05:55 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 20 Feb 2014 20:05:55 +0000 Subject: NTP DRDos Blog post In-Reply-To: <53065CD5.7060007@nuclearfallout.net> References: <20140220161445.GJ67472@burnout.tpb.net> <53062C1E.1070402@gameservers.com> <1A823676-45C9-471F-A785-3753BA272EC0@arbor.net> <53065995.2010306@nuclearfallout.net> <54862F77-A2CC-4F54-A261-9195133FDB50@arbor.net> <53065CD5.7060007@nuclearfallout.net> Message-ID: <20960651-43FB-4A99-A777-ABA7982FEEF7@arbor.net> On Feb 21, 2014, at 2:51 AM, John wrote: > I know how much Gibson is hated in some circles, He isn't/wasn't part of the operational community. It sure looks like you're right, he coined it then - as a marketing term, for marketing himself, heh. Maybe that's one of the reasons it's so disliked. ;> > I read that in 2002, did other research about it in 2002, saw reflected attacks in 2002. I saw reflected/amplified attacks in 2002, too, and that's what I called them. So did everyone else I worked with to mitigate them, heh. And I'm really going to shut up about this, now. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From eugen at imacandi.net Thu Feb 20 20:09:24 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 20 Feb 2014 22:09:24 +0200 Subject: VMware Training In-Reply-To: <64B7A262-4EDD-46A6-B2E2-30814897FA5C@iwiring.net> References: <4299424.9404.1392840366103.JavaMail.root@benjamin.baylink.com> <64733bcf-9511-4733-9eb7-071dbff36282@email.android.com> <64B7A262-4EDD-46A6-B2E2-30814897FA5C@iwiring.net> Message-ID: On Thu, Feb 20, 2014 at 9:49 PM, Dan Shoop wrote: > > On Feb 20, 2014, at 1:48 PM, Jimmy Hess wrote: > > > The locking restrictions are for your own protection. If the filesystem > > inside your virtual disks is not a clustered filesystem; > > two instances of a VM simultaneously mounting the same NTFS volume and > > writing some things, is an absolute disaster. > > > > > > Under normal circumstances, two applications should never be writing to > > the same file. This is true on clustered filesystems. > > This is true when running multiple applications on a single computer. > > Why should "two applications should never be writing to the same file"? In > a real clustered *file*system this is exactly what you want. The same > logical volume mounted across host cluster members, perhaps geodistantly > located, each having access at the record level to the data. This permits > HA and for the application to be distributed across cluster nodes. If a > host node is lost then the application stays running. If the physical > volume is unavailable then logically shadowing the volume across node > members or storage controllers / SANs permits fault tolerance. You don't > need to "fail disks over" (really logical volumes) as they are resilient > from the start, they just don't fail. When the shadow members return they > replay journals or resilver if the journals are lost. > There is a lot of misunderstanding here about how ESXi works in a multiple host environment. There are a lot of abstraction layers. Physical disk -> VMFS -> VMDK files that represent the VM HDD -> VM -> VM filesystem (NTFS, ext3/4, xfs etc). The physical disk can be whatever device a controller presents (like a 4 way FC connection for the same LUN). What we are discussing here is the VMFS capabilities. Also, what I am saying is that the VM will be very upset when it's HDD contents are changed without notice. This is why ESXi has a lock per VM that notifies other ESXi hosts trying to access a particular VM folder that "hey, it's in use, leave it alone". And speaking of clustered filesystems, while you may read/write on the at the same time, except for file storage I do not know of any application that has no objections that the files it works with have their contents modified - think database systems. > > I'd note that this can be accomplished just so long as you have a common > disk format across the OS nodes. > > These problems were all resolved 40 years ago in mainframe and supermini > systems. They're not new. VMware has been slowly reinventing -- more > accurately rediscovering -- well known HA techniques as it's trying to > mature. And it still has a lot of catching up to do. It's the same tale > that microcomputers have been doing for decades as they've come into use as > servers. > > Depending on the use case you may be right or wrong :) > However I'm not sure what all of this has to do with network operations. ;) What, you want political discussions instead? :) From aaron at heyaaron.com Thu Feb 20 20:11:08 2014 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 20 Feb 2014 12:11:08 -0800 Subject: comcast business service In-Reply-To: References: Message-ID: If it's one of their new Netgear-branded modems, see if you can get your tech to dig up an SMC. We had the same issue. They swapped out one Netgear modem for another Netgear and the problem continued. The phone techs couldn't see the problem and kept blaming our equipment. They finally sent out one of the 'senior' engineers I had worked with before on other jobs. He managed to get a hold of one of the SMCs from their warehouse. No more issues. -A On Thu, Feb 20, 2014 at 1:08 AM, shawn wilson wrote: > A while ago I got Comcast's business service. Semi-idle connections > are get dropped (I haven't really diagnosed this - I just no that it > isn't the client or server but some network in between). However the > second and most obvious issue is that intermittently, the service will > grind to a halt: > --- 8.8.8.8 ping statistics --- > 37 packets transmitted, 34 received, 8% packet loss, time 36263ms > rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 > > After a modem reboot, it goes normal: > --- 8.8.8.8 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3003ms > rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms > > This seems to happen about once or twice a day. I can't attribute it > to any type of traffic or number of connections. All of the rest of > the network equipment is the same and the behavior persists when a > computer is plugged directly into the modem. I called Comcast and they > said they didn't see anything even when I was experiencing ridiculous > ping times. I tend to think it's an issue with the 'modem' but I'm not > sure what the issue might be or how to reproduce it when asked to if I > tell them to look at it. > > From ag4ve.us at gmail.com Thu Feb 20 20:35:10 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 20 Feb 2014 15:35:10 -0500 Subject: comcast business service In-Reply-To: References: Message-ID: Thanks. The tech said they looked at signal levels when I called and didn't see anything. I didn't have a baseline at the time (I do now) and assumed they'd see something there if there was something. I do have the Netgear. So I'll keep this in mind when I call them again (assuming it's really not a noise issue) though I'm not sure exactly what happened here or how I can get them to try the same thing? On Feb 20, 2014 3:11 PM, "Aaron C. de Bruyn" wrote: > If it's one of their new Netgear-branded modems, see if you can get your > tech to dig up an SMC. > > We had the same issue. They swapped out one Netgear modem for another > Netgear and the problem continued. The phone techs couldn't see the problem > and kept blaming our equipment. They finally sent out one of the 'senior' > engineers I had worked with before on other jobs. He managed to get a hold > of one of the SMCs from their warehouse. No more issues. > > -A > > > On Thu, Feb 20, 2014 at 1:08 AM, shawn wilson wrote: > >> A while ago I got Comcast's business service. Semi-idle connections >> are get dropped (I haven't really diagnosed this - I just no that it >> isn't the client or server but some network in between). However the >> second and most obvious issue is that intermittently, the service will >> grind to a halt: >> --- 8.8.8.8 ping statistics --- >> 37 packets transmitted, 34 received, 8% packet loss, time 36263ms >> rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 >> >> After a modem reboot, it goes normal: >> --- 8.8.8.8 ping statistics --- >> 4 packets transmitted, 4 received, 0% packet loss, time 3003ms >> rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms >> >> This seems to happen about once or twice a day. I can't attribute it >> to any type of traffic or number of connections. All of the rest of >> the network equipment is the same and the behavior persists when a >> computer is plugged directly into the modem. I called Comcast and they >> said they didn't see anything even when I was experiencing ridiculous >> ping times. I tend to think it's an issue with the 'modem' but I'm not >> sure what the issue might be or how to reproduce it when asked to if I >> tell them to look at it. >> >> > From edwardroels at gmail.com Thu Feb 20 20:41:27 2014 From: edwardroels at gmail.com (Edward Roels) Date: Thu, 20 Feb 2014 15:41:27 -0500 Subject: Filter NTP traffic by packet size? Message-ID: Curious if anyone else thinks filtering out NTP packets above a certain packet size is a good or terrible idea. >From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are typical for a client to successfully synchronize to an NTP server. If I query a server for it's list of peers (ntpq -np ) I've seen packets as large as 522 bytes in a single packet in response to a 54 byte query. I'll admit I'm not 100% clear of the what is happening protocol-wise when I perform this query. I see there are multiple packets back forth between me and the server depending on the number of peers it has? Would I be breaking something important if I started to filter NTP packets > 200 bytes into my network? From jw at nuclearfallout.net Thu Feb 20 20:51:53 2014 From: jw at nuclearfallout.net (John Weekes) Date: Thu, 20 Feb 2014 12:51:53 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: Message-ID: <53066AE9.6010800@nuclearfallout.net> On 2/20/2014 12:41 PM, Edward Roels wrote: > Curious if anyone else thinks filtering out NTP packets above a certain > packet size is a good or terrible idea. > > From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are > typical for a client to successfully synchronize to an NTP server. > > If I query a server for it's list of peers (ntpq -np ) I've seen > packets as large as 522 bytes in a single packet in response to a 54 byte > query. I'll admit I'm not 100% clear of the what is happening > protocol-wise when I perform this query. I see there are multiple packets > back forth between me and the server depending on the number of peers it > has? > > > Would I be breaking something important if I started to filter NTP packets >> 200 bytes into my network? If your equipment supports this, and you're seeing reflected NTP attacks, then it is an effective stopgap to block nearly all of the inbound attack traffic to affected hosts. Some still comes through from NTP servers running on nonstandard ports, but not much. Standard IPv4 NTP response packets are 76 bytes (plus any link-level headers), based on my testing. I have been internally filtering packets of other sizes against attack targets for some time now with no ill-effect. -John From jared at puck.nether.net Thu Feb 20 21:03:49 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Feb 2014 16:03:49 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: <53066AE9.6010800@nuclearfallout.net> References: <53066AE9.6010800@nuclearfallout.net> Message-ID: <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> On Feb 20, 2014, at 3:51 PM, John Weekes wrote: > On 2/20/2014 12:41 PM, Edward Roels wrote: >> Curious if anyone else thinks filtering out NTP packets above a certain >> packet size is a good or terrible idea. >> >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are >> typical for a client to successfully synchronize to an NTP server. >> >> If I query a server for it's list of peers (ntpq -np ) I've seen >> packets as large as 522 bytes in a single packet in response to a 54 byte >> query. I'll admit I'm not 100% clear of the what is happening >> protocol-wise when I perform this query. I see there are multiple packets >> back forth between me and the server depending on the number of peers it >> has? >> >> >> Would I be breaking something important if I started to filter NTP packets >>> 200 bytes into my network? > > If your equipment supports this, and you're seeing reflected NTP attacks, then it is an effective stopgap to block nearly all of the inbound attack traffic to affected hosts. Some still comes through from NTP servers running on nonstandard ports, but not much. > > Standard IPv4 NTP response packets are 76 bytes (plus any link-level headers), based on my testing. I have been internally filtering packets of other sizes against attack targets for some time now with no ill-effect. You can filter packets that are 440 bytes in size and it will do a lot to help the problem, but make sure you conjoin these with protocol udp and port=123 rules to avoid collateral damage. You may also want to look at filtering UDP/80 outright as well, as that is commonly used as an "I'm going to attack port 80" by attackers that don't quite understand the difference between UDP and TCP. Next up, we will see the proto=0 and proto=255 attacks again.. - Jared From laszlo at heliacal.net Thu Feb 20 21:05:24 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 20 Feb 2014 21:05:24 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: References: Message-ID: <87CA372C-A7D3-4365-ABDE-85E6A65334B3@heliacal.net> Filtering will always break something. Filtering 'abusive' network traffic is intentionally difficult - you either just let it be, or you filter it along with the 'good' network traffic that it's pretending to be. How can you even tell it's NTP traffic - maybe by the port numbers? What if someone is running OpenVPN on those ports? What about IP options? Maybe some servers return extra data? This is really not a network operator problem, it's an application problem if anything. While it makes sense to temporarily filter a large flood to keep the rest of your customers online, it's a very blunt instrument, as the affected customer is usually still taken offline - but I'm talking about specific targeted filters anyway. Doing blanket filtering based on packet sizes is sure to generate some really hard to debug failure cases that you didn't account for. Unfortunately, as long as Facebook loads, most of the users are happy, and so these kinds of practices will likely be implemented in many places, with some people opting to completely filter NTP or UDP. Maybe it will buy you a little peace and quiet today, but tomorrow it's just going to be happening on a different port/protocol that you can't inspect deeply, and you don't dare block. I can imagine 10 years from now, where we're writing code that fragments replies into 100 byte packets to get past this, and everyone loses. Your filter is circumvented, the application performs slower, and the 'bad guys' found another way that you can't filter. When all that's left is TCP port 443, that's what all the 'abuse' traffic will be using too. Laszlo On Feb 20, 2014, at 8:41 PM, Edward Roels wrote: > Curious if anyone else thinks filtering out NTP packets above a certain > packet size is a good or terrible idea. > > From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are > typical for a client to successfully synchronize to an NTP server. > > If I query a server for it's list of peers (ntpq -np ) I've seen > packets as large as 522 bytes in a single packet in response to a 54 byte > query. I'll admit I'm not 100% clear of the what is happening > protocol-wise when I perform this query. I see there are multiple packets > back forth between me and the server depending on the number of peers it > has? > > > Would I be breaking something important if I started to filter NTP packets >> 200 bytes into my network? From shoop at iwiring.net Thu Feb 20 21:14:12 2014 From: shoop at iwiring.net (Dan Shoop) Date: Thu, 20 Feb 2014 16:14:12 -0500 Subject: comcast business service In-Reply-To: References: Message-ID: On Feb 20, 2014, at 4:08 AM, shawn wilson wrote: > A while ago I got Comcast's business service. Semi-idle connections > are get dropped (I haven't really diagnosed this - I just no that it > isn't the client or server but some network in between). However the > second and most obvious issue is that intermittently, the service will > grind to a halt: > --- 8.8.8.8 ping statistics --- > 37 packets transmitted, 34 received, 8% packet loss, time 36263ms > rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 > > After a modem reboot, it goes normal: > --- 8.8.8.8 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3003ms > rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms > > This seems to happen about once or twice a day. I can't attribute it > to any type of traffic or number of connections. All of the rest of > the network equipment is the same and the behavior persists when a > computer is plugged directly into the modem. I called Comcast and they > said they didn't see anything even when I was experiencing ridiculous > ping times. I tend to think it's an issue with the 'modem' but I'm not > sure what the issue might be or how to reproduce it when asked to if I > tell them to look at it. I?ve seen this happen before with various cable ISPs. I?d concur with the poster suggesting intermittent noise on the cable segment as a likely culprit. Also if you have a cable modem that binds multiple channels for higher bandwidth this can also be problematic, especially with the noise. Signals will look good to the NOC but it?s not the signal ?level" that?s the issue it?s the signal to noise level. Noise has to be measured locally and techs don?t always check SNL. Also check to see if the packets aren?t actually being dropped but just taking longer than ping is looking for. Also check for out of sequence packets returned. These can indicate flapping of a bonded circuit or the bonded circuit experiencing noise. Try seeing if you disconnect everything and get a straight run to the demarc, with a know and tested out good cable, if the problem doesn?t ever occur. This could indicate noise on the cable in your premise. But I?ve experienced this same problem with noise coming through the demarc. I?ve also seen levels too hot beyond the demarc causing similar problems too. HTH. -d ----- Dan Shoop shoop at iwiring.net 1-646-402-5293 (GoogleVoice) From rayw at rayw.net Thu Feb 20 21:26:43 2014 From: rayw at rayw.net (Ray Wong) Date: Thu, 20 Feb 2014 13:26:43 -0800 Subject: comcast business service In-Reply-To: References: Message-ID: They often say everything looks okay. I can recall one conversation where the tech said he was talking to my modem and there were no problems all the way to it. I replied that it was unplugged in my hand because I had done so to read the serial number to him, so he couldn't be talking to it. Service did get better after that. :) -R> On Thu, Feb 20, 2014 at 12:35 PM, shawn wilson wrote: > Thanks. The tech said they looked at signal levels when I called and didn't > see anything. I didn't have a baseline at the time (I do now) and assumed > they'd see something there if there was something. > > I do have the Netgear. So I'll keep this in mind when I call them again > (assuming it's really not a noise issue) though I'm not sure exactly what > happened here or how I can get them to try the same thing? > On Feb 20, 2014 3:11 PM, "Aaron C. de Bruyn" wrote: > > > If it's one of their new Netgear-branded modems, see if you can get your > > tech to dig up an SMC. > > > > We had the same issue. They swapped out one Netgear modem for another > > Netgear and the problem continued. The phone techs couldn't see the > problem > > and kept blaming our equipment. They finally sent out one of the > 'senior' > > engineers I had worked with before on other jobs. He managed to get a > hold > > of one of the SMCs from their warehouse. No more issues. > > > > -A > > > > > > On Thu, Feb 20, 2014 at 1:08 AM, shawn wilson > wrote: > > > >> A while ago I got Comcast's business service. Semi-idle connections > >> are get dropped (I haven't really diagnosed this - I just no that it > >> isn't the client or server but some network in between). However the > >> second and most obvious issue is that intermittently, the service will > >> grind to a halt: > >> --- 8.8.8.8 ping statistics --- > >> 37 packets transmitted, 34 received, 8% packet loss, time 36263ms > >> rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 > >> > >> After a modem reboot, it goes normal: > >> --- 8.8.8.8 ping statistics --- > >> 4 packets transmitted, 4 received, 0% packet loss, time 3003ms > >> rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms > >> > >> This seems to happen about once or twice a day. I can't attribute it > >> to any type of traffic or number of connections. All of the rest of > >> the network equipment is the same and the behavior persists when a > >> computer is plugged directly into the modem. I called Comcast and they > >> said they didn't see anything even when I was experiencing ridiculous > >> ping times. I tend to think it's an issue with the 'modem' but I'm not > >> sure what the issue might be or how to reproduce it when asked to if I > >> tell them to look at it. > >> > >> > > > From james.cutler at consultant.com Thu Feb 20 21:40:26 2014 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 20 Feb 2014 16:40:26 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: <87CA372C-A7D3-4365-ABDE-85E6A65334B3@heliacal.net> References: <87CA372C-A7D3-4365-ABDE-85E6A65334B3@heliacal.net> Message-ID: <8CFD1BE7-6143-4CF7-A1F0-594E134DE5DC@consultant.com> On Feb 20, 2014, at 4:05 PM, Laszlo Hanyecz wrote: > Filtering will always break something. Filtering 'abusive' network traffic is intentionally difficult - you either just let it be, or you filter it along with the 'good' network traffic that it's pretending to be. How can you even tell it's NTP traffic - maybe by the port numbers? What if someone is running OpenVPN on those ports? What about IP options? Maybe some servers return extra data? > > This is really not a network operator problem, it's an application problem if anything. While it makes sense to temporarily filter a large flood to keep the rest of your customers online, it's a very blunt instrument, as the affected customer is usually still taken offline - but I'm talking about specific targeted filters anyway. Doing blanket filtering based on packet sizes is sure to generate some really hard to debug failure cases that you didn't account for. > > Unfortunately, as long as Facebook loads, most of the users are happy, and so these kinds of practices will likely be implemented in many places, with some people opting to completely filter NTP or UDP. Maybe it will buy you a little peace and quiet today, but tomorrow it's just going to be happening on a different port/protocol that you can't inspect deeply, and you don't dare block. I can imagine 10 years from now, where we're writing code that fragments replies into 100 byte packets to get past this, and everyone loses. Your filter is circumvented, the application performs slower, and the 'bad guys' found another way that you can't filter. When all that's left is TCP port 443, that's what all the 'abuse' traffic will be using too. > > Laszlo > > > On Feb 20, 2014, at 8:41 PM, Edward Roels wrote: > >> Curious if anyone else thinks filtering out NTP packets above a certain >> packet size is a good or terrible idea. >> >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are >> typical for a client to successfully synchronize to an NTP server. >> >> If I query a server for it's list of peers (ntpq -np ) I've seen >> packets as large as 522 bytes in a single packet in response to a 54 byte >> query. I'll admit I'm not 100% clear of the what is happening >> protocol-wise when I perform this query. I see there are multiple packets >> back forth between me and the server depending on the number of peers it >> has? >> >> >> Would I be breaking something important if I started to filter NTP packets >>> 200 bytes into my network? > > While filtering NTP packets may be a work-around, for any network with firewall isolation from the general Internet it would make more sense to: 1. Establish an internal peer group of NTP Server instances. As noted, a distributed group of four is the absolute minimum, six is more than sufficient. 2. Default restrict noquery on all internal NTP servers. 2. Use a common list of external NTP servers for all internal servers. 3. Provide that list of external NTP servers to the firewall engineer to add to a permit ACL (deny all others) James R. Cutler - james.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From damian at google.com Thu Feb 20 22:12:15 2014 From: damian at google.com (Damian Menscher) Date: Thu, 20 Feb 2014 14:12:15 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch wrote: > > On Feb 20, 2014, at 3:51 PM, John Weekes wrote: > > On 2/20/2014 12:41 PM, Edward Roels wrote: > >> Curious if anyone else thinks filtering out NTP packets above a certain > >> packet size is a good or terrible idea. > >> > >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 > are > >> typical for a client to successfully synchronize to an NTP server. > >> > >> If I query a server for it's list of peers (ntpq -np ) I've seen > >> packets as large as 522 bytes in a single packet in response to a 54 > byte > >> query. I'll admit I'm not 100% clear of the what is happening > >> protocol-wise when I perform this query. I see there are multiple > packets > >> back forth between me and the server depending on the number of peers it > >> has? > > > > If your equipment supports this, and you're seeing reflected NTP > attacks, then it is an effective stopgap to block nearly all of the inbound > attack traffic to affected hosts. Some still comes through from NTP servers > running on nonstandard ports, but not much. > Also, don't forget to ask those sending the attack traffic to trace where the spoofed packets ingressed their networks. > Standard IPv4 NTP response packets are 76 bytes (plus any link-level > headers), based on my testing. I have been internally filtering packets of > other sizes against attack targets for some time now with no ill-effect. > > You can filter packets that are 440 bytes in size and it will do a lot to > help the problem, but make sure you conjoin these with protocol udp and > port=123 rules to avoid collateral damage. > Preferably just source-port 123. You may also want to look at filtering UDP/80 outright as well, as that is > commonly used as an "I'm going to attack port 80" by attackers that don't > quite understand the difference between UDP and TCP. > Please don't filter UDP/80. It's used by QUIC ( http://en.wikipedia.org/wiki/QUIC). Damian From jneiberger at gmail.com Thu Feb 20 22:13:23 2014 From: jneiberger at gmail.com (John Neiberger) Date: Thu, 20 Feb 2014 15:13:23 -0700 Subject: prefix advertisement In-Reply-To: <4A638950B27347428796CE85845BE09D238888C433@C1MBC130.corp.alliance.lan> References: <4A638950B27347428796CE85845BE09D238888C433@C1MBC130.corp.alliance.lan> Message-ID: Did someone get back to you on this yet? If not, let me know. Thanks, John On Thu, Feb 20, 2014 at 7:28 AM, Russell, Ben < ben.russell at countryfinancial.com> wrote: > Can someone from Comcast BGP team contact me off list? I am seeing AS > 33491 advertising one of our prefixes. > > Thanks > > -Ben > > From jfbeam at gmail.com Thu Feb 20 22:25:33 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 20 Feb 2014 17:25:33 -0500 Subject: question about AS relationship In-Reply-To: <5305B983.1080406@gmail.com> References: <5305B983.1080406@gmail.com> Message-ID: On Thu, 20 Feb 2014 03:14:59 -0500, Song Li wrote: > I have one simple question: as for AS relationship, should customer tell > its provider the AS# of its own customers, or the provider have the > right to require its customers to do that? (Having been on both ends of this...) If you want me to carry their traffic, yes, I need to know their address block(s) AND the ASN appearing behind yours. I will, in turn, have to provide that to my upstream provider(s). NOBODY should be blindly accepting routing information from ANYONE, EVER. That's how people appropriate address space. --Ricky From babydr at baby-dragons.com Fri Feb 21 00:05:25 2014 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Thu, 20 Feb 2014 15:05:25 -0900 (AKST) Subject: NTP DRDos Blog post In-Reply-To: References: Message-ID: Hello Harlen , On Wed, 19 Feb 2014, Harlan Stenn wrote: > Folks, > I just posted http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ . wget http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ --2014-02-20 15:03:13-- http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ Resolving nwtime.org (nwtime.org)... 140.211.15.245 Connecting to nwtime.org (nwtime.org)|140.211.15.245|:80... failed: Connection refused. I get the same type message from 3 differant sytems that I have access from & three differant browsers . Did the url change or get locked down ? Tia , JimL > In general we've never allowed comments to blog posts on that site; > we're currently discussing if we should allow them for this post. > I'd love to hear any feedback about the post. > Thanks... -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From DStaal at usa.net Fri Feb 21 00:29:43 2014 From: DStaal at usa.net (Daniel Staal) Date: Thu, 20 Feb 2014 19:29:43 -0500 Subject: spamassassin In-Reply-To: <10967671F9548B4D5F29CAC7@[192.168.1.50]> References: <5304C3DF.8000805@viagenie.ca> <20140219190150.35f3a504.gem@rellim.com> <10967671F9548B4D5F29CAC7@[192.168.1.50]> Message-ID: <97C4BC3B3C8BED765AA64450@[192.168.1.50]> I'm going to forward on what's probably a 'final disposition' post on this below. Note the behavior of the BAYES_999 rule is going to change dramatically. (It will be *in addition* to the BAYES_99 rule, instead of replacing it for messages with the appropriate bayes score.) From: "Kevin A. McGrail" > > As of about 10:30EST Tonight, I expect that versions 3.3.X will be able > to use sa-update to receive an update that includes BAYES_99 as it used > to exist + BAYES_999 which overlaps with BAYES_99 and adds 0.2 to the > score. > > By about 4AM tomorrow, version 3.4.1 will have an update though likely no > one can access that update. > > Tomorrow morning by about 10AM, I will update 3.4.0 manually to receive > the 3.4.1 update. > > So as of ~1 hour past the times above based on the version in use to > allow for DNS ttl and mirror updates, I would recommend people run > sa-update and remove any manual edits for rules named BAYES_99 or > BAYES_999. If they have manual scoring for these, they will want to > review those scores for their own installation. BAYES_99 scores in the > 3.75 range and BAYES_999 will score in the 0.25 range. Anything outside > of those scores should be done understanding your own Bayesian database. > > They can confirm they received the correct update if the rule score for > BAYES_999 changes to 0.2, i.e. for a default path 3.4.0 installation: > > grep BAYES_999 > /var/lib/spamassassin/3.004000/updates_spamassassin_org/50_scores.cf > > gives > > score BAYES_999 0 0 4.0 3.7 > > Tomorrow, this should change to 0.2. > > regards, > KAM From jared at puck.nether.net Fri Feb 21 00:31:50 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Feb 2014 19:31:50 -0500 Subject: NTP DRDos Blog post In-Reply-To: References: Message-ID: <1D614FF8-8F34-4F21-A8E9-5F3789CCD8BE@puck.nether.net> I was seeing database connect errors earlier. I suspect the host resources are limited. Jared Mauch > On Feb 20, 2014, at 7:05 PM, "Mr. James W. Laferriere" wrote: > > Hello Harlen , > >> On Wed, 19 Feb 2014, Harlan Stenn wrote: >> Folks, >> I just posted http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ . > wget http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ > --2014-02-20 15:03:13-- http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ > Resolving nwtime.org (nwtime.org)... 140.211.15.245 > Connecting to nwtime.org (nwtime.org)|140.211.15.245|:80... failed: Connection refused. > > I get the same type message from 3 differant sytems that I have access from & three differant browsers . Did the url change or get locked down ? > Tia , JimL > >> In general we've never allowed comments to blog posts on that site; >> we're currently discussing if we should allow them for this post. >> I'd love to hear any feedback about the post. >> Thanks... > > -- > +------------------------------------------------------------------+ > | James W. Laferriere | System Techniques | Give me VMS | > | Network&System Engineer | 3237 Holden Road | Give me Linux | > | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | > +------------------------------------------------------------------+ From bedard.phil at gmail.com Fri Feb 21 00:37:13 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 20 Feb 2014 19:37:13 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: References: Message-ID: On 2/20/14, 3:41 PM, "Edward Roels" wrote: >Curious if anyone else thinks filtering out NTP packets above a certain >packet size is a good or terrible idea. > >From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 >are >typical for a client to successfully synchronize to an NTP server. > >If I query a server for it's list of peers (ntpq -np ) I've seen >packets as large as 522 bytes in a single packet in response to a 54 byte >query. I'll admit I'm not 100% clear of the what is happening >protocol-wise when I perform this query. I see there are multiple packets >back forth between me and the server depending on the number of peers it >has? > > >Would I be breaking something important if I started to filter NTP packets >> 200 bytes into my network? We are filtering a range of packet sizes for UDP/123 at the edge and it has definitely helped thwart some of the NTP attacks. I hate to do blanket ACLs blocking traffic but multi-Gbps of attack traffic (not counting the reflected traffic) is hard to ignore and it's worth the risk of blocking a minute amount of legitimate traffic. Phil From dmiller at tiggee.com Fri Feb 21 00:39:03 2014 From: dmiller at tiggee.com (David Miller) Date: Thu, 20 Feb 2014 19:39:03 -0500 Subject: NTP DRDos Blog post In-Reply-To: References: Message-ID: <5306A027.1030406@tiggee.com> On 2/20/2014 7:05 PM, Mr. James W. Laferriere wrote: > Hello Harlen , > > On Wed, 19 Feb 2014, Harlan Stenn wrote: >> Folks, >> I just posted http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ . > wget http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ > --2014-02-20 15:03:13-- > http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ > Resolving nwtime.org (nwtime.org)... 140.211.15.245 > Connecting to nwtime.org (nwtime.org)|140.211.15.245|:80... failed: > Connection refused. > > I get the same type message from 3 differant sytems that I have > access from & three differant browsers . Did the url change or get > locked down ? > Tia , JimL I can't get to any part of the nwtime.org web site. Google has a cached copy of the article. Search for "site:nwtime.org ntp drdos attacks" -DMM > >> In general we've never allowed comments to blog posts on that site; >> we're currently discussing if we should allow them for this post. >> I'd love to hear any feedback about the post. >> Thanks... > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From sclark at netwolves.com Thu Feb 20 18:08:05 2014 From: sclark at netwolves.com (Steve Clark) Date: Thu, 20 Feb 2014 13:08:05 -0500 Subject: random dns queries with random sources In-Reply-To: References: <5304201A.3040508@ttec.com> <5305248A.4030406@necom830.hpcl.titech.ac.jp> Message-ID: <53064485.3060603@netwolves.com> On 02/20/2014 08:57 AM, Pavel Zeleny wrote: > Masataka Ohta necom830.hpcl.titech.ac.jp> writes: > >> Joe Maimon wrote: >> >>> What is the purpose of this? > ... >> Masataka Ohta >> > Hi guys, > for a second, have you any clue how to block this traffic on DNS server > side? As our company operates recursive resolvers for our customers, we can > see this weird traffic concentrated in our logs. It started Feb 3 about > 16:30 (GMT/UTC+1). Very large amount of DNS A queries are sent from source > IP addresses of our customers, and they always looks like > [randomjunk].SLD.com. We have seen 143 this SLD's so far, and we had to > block it manually one by one. > We suspect some kind of botnet, because attack wave with new SLD's starts at > the same time, coming from broad range of valid non-spoofed source IP > addresses. Content of UDP packets belonging to this traffic doesn't seem to > have any identical pattern. > > Any ideas are highly appreciated. > Thank you! > > Pavel Zeleny > > iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP So, every prefix (length 28) can send 20 r/s with allowed bursts of 100. This requires a Netfilter >= 1.4 (recent options of module hashlimit). -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From mark.tinka at seacom.mu Fri Feb 21 01:42:43 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Feb 2014 03:42:43 +0200 Subject: question about AS relationship In-Reply-To: References: <5305B983.1080406@gmail.com> Message-ID: <201402210342.47859.mark.tinka@seacom.mu> On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote: > so, yes. pleass tell your upstream your customers so > proper filtering can be automated and implemented. > > don't turn up bgp customers without filtering, that kills > kittens. For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as "a reasonably large tier"), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A loooooooong way away... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Feb 21 01:47:40 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Feb 2014 03:47:40 +0200 Subject: question about AS relationship In-Reply-To: References: <5305B983.1080406@gmail.com> Message-ID: <201402210347.40835.mark.tinka@seacom.mu> On Friday, February 21, 2014 12:25:33 AM Ricky Beam wrote: > NOBODY should be blindly accepting routing information > from ANYONE, EVER. That's how people appropriate address > space. The reality is that this is (still) happening. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rdobbins at arbor.net Fri Feb 21 02:55:06 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 21 Feb 2014 02:55:06 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: References: Message-ID: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> On Feb 21, 2014, at 3:41 AM, Edward Roels wrote: > From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are typical for a client to successfully synchronize to an NTP server. Correct. 90 bytes = 76 bytes + Ethernet framing. Filtering out packets this size from UDP/anything to UDP/123 allows time-sync requests and responses to work, but squelches both the level-6/-7 commands used to trigger amplification as well as amplified attack traffic. Operators are using this size-based filtering to effect without breaking the world. Be sure to pilot this first, and understand whether packet-size classification on your hardware of choice includes framing or not. Also, note that this filtering should be utilized to mitigate attacks, not as a permanent policy. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Fri Feb 21 03:00:27 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 21 Feb 2014 03:00:27 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> References: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> Message-ID: <3B47964F-4802-49E5-B673-66A5591D8077@arbor.net> On Feb 21, 2014, at 9:55 AM, Dobbins, Roland wrote: > Filtering out packets this size from UDP/anything to UDP/123 allows time-sync requests and responses to work, but squelches both the level-6/-7 commands used to trigger amplification as well as amplified attack traffic. Also, the reverse - UDP/123 - UDP/anything, for the amplified attack traffic. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Fri Feb 21 03:08:16 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 21 Feb 2014 03:08:16 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> References: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> Message-ID: <70B454E6-B589-4D93-8D9F-6A7B6B5C728B@arbor.net> On Feb 21, 2014, at 9:55 AM, Dobbins, Roland wrote: > Filtering out packets this size from UDP/anything to UDP/123 allows time-sync requests and responses to work, but squelches both the level-6/-7 commands used to trigger amplification as well as amplified attack traffic. That should read, filtering out packets **** NOT **** that size. Lack of sleep, apologies. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From randy at psg.com Fri Feb 21 03:10:16 2014 From: randy at psg.com (Randy Bush) Date: Fri, 21 Feb 2014 11:10:16 +0800 Subject: spamassassin In-Reply-To: <10967671F9548B4D5F29CAC7@[192.168.1.50]> References: <5304C3DF.8000805@viagenie.ca> <20140219190150.35f3a504.gem@rellim.com> <10967671F9548B4D5F29CAC7@[192.168.1.50]> Message-ID: > The correct score has been pushed, as Simon Perreault mentioned. Taking > out anything you've done and running sa-update should get you a working > ruleset. thank you randy From tglassey at earthlink.net Fri Feb 21 04:14:30 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Thu, 20 Feb 2014 20:14:30 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: <5306D2A6.9070103@earthlink.net> Type Enforcement in the OS Kernel is the place to do that. Todd On 2/20/2014 2:12 PM, Damian Menscher wrote: > On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch wrote: >> On Feb 20, 2014, at 3:51 PM, John Weekes wrote: >>> On 2/20/2014 12:41 PM, Edward Roels wrote: >>>> Curious if anyone else thinks filtering out NTP packets above a certain >>>> packet size is a good or terrible idea. >>>> >>>> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 >> are >>>> typical for a client to successfully synchronize to an NTP server. >>>> >>>> If I query a server for it's list of peers (ntpq -np ) I've seen >>>> packets as large as 522 bytes in a single packet in response to a 54 >> byte >>>> query. I'll admit I'm not 100% clear of the what is happening >>>> protocol-wise when I perform this query. I see there are multiple >> packets >>>> back forth between me and the server depending on the number of peers it >>>> has? >>> If your equipment supports this, and you're seeing reflected NTP >> attacks, then it is an effective stopgap to block nearly all of the inbound >> attack traffic to affected hosts. Some still comes through from NTP servers >> running on nonstandard ports, but not much. >> > Also, don't forget to ask those sending the attack traffic to trace where > the spoofed packets ingressed their networks. > > > Standard IPv4 NTP response packets are 76 bytes (plus any link-level >> headers), based on my testing. I have been internally filtering packets of >> other sizes against attack targets for some time now with no ill-effect. >> >> You can filter packets that are 440 bytes in size and it will do a lot to >> help the problem, but make sure you conjoin these with protocol udp and >> port=123 rules to avoid collateral damage. >> > Preferably just source-port 123. > > You may also want to look at filtering UDP/80 outright as well, as that is >> commonly used as an "I'm going to attack port 80" by attackers that don't >> quite understand the difference between UDP and TCP. >> > Please don't filter UDP/80. It's used by QUIC ( > http://en.wikipedia.org/wiki/QUIC). > > Damian > > -- ------------- Personal Email - Disclaimers Apply From rdobbins at arbor.net Fri Feb 21 05:24:00 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 21 Feb 2014 05:24:00 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> Message-ID: <8C272008-1962-4890-AAD6-6F93A6799B7D@arbor.net> On Feb 21, 2014, at 11:40 AM, Harlan Stenn wrote: > As a reality check, with this filtering in place does "ntptrace" still work? No, it will not. In order to minimize overblocking of this nature, filtering of this nature should be used with the highest possible degree of granularity, and the minimal necessary scope. One way to accomplish this is to divert traffic towards destinations in question into a mitigation/center sinkhole, applying this filtering on the coreward interfaces of the mitigation center/sinkhole gateway (some re-injection mechanism such as GRE, VRF, selective filtering of the diversion route announcements coupled w/PBR, etc. must be used to re-inject non-matching traffic towards the destinations in question) or via other mitigation mechanisms. In emergencies, the concept of partial service recovery may dictate temporary filtering of coarser granularity in order to preserve overall network availability; we've run into situations in the past week-and-a-half where networks were experiencing severe strain due to the sheer volume of ntp reflection/amplification attack traffic, and it was necessary to start out with more general filtering, then work towards more specific filtering once the network was stabilized. But you raise a very important point which should be re-emphasized - general filtering of traffic is to be avoided whenever possible in order to avoid breaking applications/services. However, the converse notion that emergency situations sometimes entail necessary restrictions should also be taken into account. Operators should use their best judgement as to the scope of any filtering, and should always pilot any proposed mitigation methodologies prior to wider deployment. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From refresh.lsong at gmail.com Fri Feb 21 05:37:52 2014 From: refresh.lsong at gmail.com (Song Li) Date: Fri, 21 Feb 2014 13:37:52 +0800 Subject: question about AS relationship In-Reply-To: <201402210342.47859.mark.tinka@seacom.mu> References: <5305B983.1080406@gmail.com> <201402210342.47859.mark.tinka@seacom.mu> Message-ID: <5306E630.3090604@gmail.com> Thanks. In order to prevent route leaking, this imformation should be provided to providers. but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private? -- Sky Li > On Thursday, February 20, 2014 08:09:35 PM Christopher > Morrow wrote: > >> so, yes. pleass tell your upstream your customers so >> proper filtering can be automated and implemented. >> >> don't turn up bgp customers without filtering, that kills >> kittens. > For all the leaking I've seen in the last four weeks > (including a well-known operator that was involved in the > Youtube/Pakistan saga + other well-known global operators > that could be classified as "a reasonably large tier"), > we're still a long way away ensuring all customer prefixes > are filtered correctly at the inter-domain peering edge. A > loooooooong way away... > > Mark. From mark.tinka at seacom.mu Fri Feb 21 05:50:38 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Feb 2014 07:50:38 +0200 Subject: question about AS relationship In-Reply-To: <5306E630.3090604@gmail.com> References: <5305B983.1080406@gmail.com> <201402210342.47859.mark.tinka@seacom.mu> <5306E630.3090604@gmail.com> Message-ID: <201402210750.43334.mark.tinka@seacom.mu> On Friday, February 21, 2014 07:37:52 AM Song Li wrote: > Thanks. In order to prevent route leaking, this > imformation should be provided to providers. Route leaking is not only from customers-to-providers. It can also be from providers-to-providers (and from peers-to- peers). The majority of leaks I've seen in the past have been possible because some inter-provider links have not been filtered correctly, i.e., they are providing (unknown) transit where they would only be peering. It is not uncommon to see more relaxed filtering between providers/peers, e.g., AS_PATH-based only, max-prefix-based only, e.t.c., but please don't send these out to anyone else besides your customers unless the ultimate relationship calls for it. Of course, one can't guarantee that the customers you send this to won't leak it to their own transit providers. Bottom line, chasing route leaks can be a full time job. > but another question, should the AS relationships between > customer and its other neighbors (downstrem/peer/another > provider) be private? What do you mean, in terms of how they connect or in terms of the business relationship? I don't think it matters either way. The common peering, filtering and re-announcement rules apply. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From morrowc.lists at gmail.com Fri Feb 21 05:59:01 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 21 Feb 2014 00:59:01 -0500 Subject: question about AS relationship In-Reply-To: <5306E630.3090604@gmail.com> References: <5305B983.1080406@gmail.com> <201402210342.47859.mark.tinka@seacom.mu> <5306E630.3090604@gmail.com> Message-ID: On Fri, Feb 21, 2014 at 12:37 AM, Song Li wrote: > Thanks. In order to prevent route leaking, this imformation should be > provided to providers. > > but another question, should the AS relationships between customer and its > other neighbors (downstrem/peer/another provider) be private? > perhaps you should draw a little ascii art, I think you're asking: DS1 - customer - you - isp "can DS1's relationship to 'customer' be secret" no. well, not if they want: 1) to use a public ASN 2) use ip space which isn't part of 'customer' aggregate 3) want to be reachable on the internet It's safe to say that your goal as an ISP and a customer of an ISP, should be: "Make sure that all of my routes and the routes of my customers and their customers, that I'm expected to provide transit for, are in my ISP's filters." -chris (and as someelse pointed out: "If they use BGP and expect global reachabilty... then the information isn't private anyway.") > -- > Sky Li > > >> On Thursday, February 20, 2014 08:09:35 PM Christopher >> Morrow wrote: >> >>> >>> so, yes. pleass tell your upstream your customers so >>> proper filtering can be automated and implemented. >>> >>> don't turn up bgp customers without filtering, that kills >>> kittens. >> >> For all the leaking I've seen in the last four weeks >> (including a well-known operator that was involved in the >> Youtube/Pakistan saga + other well-known global operators >> that could be classified as "a reasonably large tier"), >> we're still a long way away ensuring all customer prefixes >> are filtered correctly at the inter-domain peering edge. A >> loooooooong way away... >> >> Mark. > > > From refresh.lsong at gmail.com Fri Feb 21 06:57:07 2014 From: refresh.lsong at gmail.com (Song Li) Date: Fri, 21 Feb 2014 14:57:07 +0800 Subject: question about AS relationship In-Reply-To: References: <5305B983.1080406@gmail.com> <201402210342.47859.mark.tinka@seacom.mu> <5306E630.3090604@gmail.com> Message-ID: <5306F8C3.8070400@gmail.com> +----------+ +---------+ | provider1| |provider2| +----------+ +---------+ ^ ^ | | | | +--------+ ++-------++ +----------+ |peer AS2+-----+ AS 1 +----+peer AS3 | +--------+ +---------+ +----------+ ^ ^ | | +------------+ +-------------+ |customer AS4| |customer AS5 | +------------+ +-------------+ um.... sorry, my question is: the AS relationship between AS1 and AS2/3 is peer, and AS1 cannot announce routes from AS3 to provider1 by rule. But if AS1 do it, and the realtionship between AS1 and AS3 is invisible to provider1, how can provider1 detect this route leak without knowing the privacy? In other words, could the business relationship between AS1 and AS3 be known to provider1/2? Thanks. Sky li > > perhaps you should draw a little ascii art, I think you're asking: > > DS1 - customer - you - isp > > "can DS1's relationship to 'customer' be secret" > > no. well, not if they want: > 1) to use a public ASN > 2) use ip space which isn't part of 'customer' aggregate > 3) want to be reachable on the internet > > It's safe to say that your goal as an ISP and a customer of an ISP, should be: > "Make sure that all of my routes and the routes of my customers and > their customers, that I'm expected to provide transit for, are in my > ISP's filters." > > -chris > (and as someelse pointed out: "If they use BGP and expect global > reachabilty... then the information isn't private anyway.") > >> -- >> Sky Li >> >> >>> On Thursday, February 20, 2014 08:09:35 PM Christopher >>> Morrow wrote: >>> >>>> >>>> so, yes. pleass tell your upstream your customers so >>>> proper filtering can be automated and implemented. >>>> >>>> don't turn up bgp customers without filtering, that kills >>>> kittens. >>> >>> For all the leaking I've seen in the last four weeks >>> (including a well-known operator that was involved in the >>> Youtube/Pakistan saga + other well-known global operators >>> that could be classified as "a reasonably large tier"), >>> we're still a long way away ensuring all customer prefixes >>> are filtered correctly at the inter-domain peering edge. A >>> loooooooong way away... >>> >>> Mark. >> >> >> From stenn at ntp.org Fri Feb 21 04:40:08 2014 From: stenn at ntp.org (Harlan Stenn) Date: Fri, 21 Feb 2014 04:40:08 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> References: <6684E49C-E47B-49EF-B167-4467F445AD33@arbor.net> Message-ID: "Dobbins, Roland" writes: > Operators are using this size-based filtering to effect without > breaking the world. As a reality check, with this filtering in place does "ntptrace" still work? H From mark.tinka at seacom.mu Fri Feb 21 09:13:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Feb 2014 11:13:20 +0200 Subject: question about AS relationship In-Reply-To: <5306F8C3.8070400@gmail.com> References: <5305B983.1080406@gmail.com> <5306F8C3.8070400@gmail.com> Message-ID: <201402211113.23856.mark.tinka@seacom.mu> On Friday, February 21, 2014 08:57:07 AM Song Li wrote: > the AS relationship between AS1 and AS2/3 is peer, and > AS1 cannot announce routes from AS3 to provider1 by > rule. Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in general best practice filtering rules, unless transit is requested. > But if AS1 do it, and the realtionship between AS1 > and AS3 is invisible to provider1, how can provider1 > detect this route leak without knowing the privacy? Provider-1 wouldn't care whether it's a route leak or not. In Provider-1's mind, Peer-AS3 could (suddenly) be a customer of AS1. And since AS1 is a customer of Provider-1, Provider-1 will be happy to move those packets along as it represents more revenue for Provider-1 (more so if traffic is sold on a 95th percentile or volume utilization basis). It is, really, up to AS3 to detect that AS1 has leaked its routes (or paths, to be precise) to Provider-1, and then pick up the phone and scream at AS1 to get that leak fixed plugged. Of course, all of this is a moot point if Provider-1 is a good provider and makes sure they only accept routes and paths from AS3 that AS3 should be sending to Provider-1 in the first place. But as we know, some providers are a bit (actually, very) lazy here. > In other words, could the business relationship between > AS1 and AS3 be known to provider1/2? Not really (or not that easily, to be specific). With enough time and access to several looking glasses and public route servers, one could "infer" (to a certain degree of error) business relationships between peering relationships, i.e., whether they relationships are customer, peer or provider. But in your particular case, unless AS3 has a direct connection toward Provider-1/2 (where a route leak would introduce more problems), Provider-1/2 don't really care about whether this is a leak or not from AS1. But again, this whole discussion is mooted if Provider-1/2 do proper background checks and filtering before they turn- up the service for AS1. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nanog at nq4i.com Fri Feb 21 10:06:41 2014 From: nanog at nq4i.com (Bobby Lacey) Date: Fri, 21 Feb 2014 05:06:41 -0500 Subject: Atlanta - Patch Cables Message-ID: In Atlanta doing an install for a client this weekend and it appears that the fiber/ethernet patch cables won't be delivered in time from supplier. Would anyone know of a good resource for patch cables (both fiber and ethernet) in the metro area? Just wondering if there are any other resources for these? Frys? Offlist please. Thank you! Bobby From ag4ve.us at gmail.com Fri Feb 21 10:23:07 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 21 Feb 2014 05:23:07 -0500 Subject: comcast business service In-Reply-To: References: Message-ID: Works: Downstream Channel Downstream Frequency525000000 Hz561000000 Hz567000000 Hz573000000 Hz579000000 Hz Lock StatusLockedLockedLockedLockedLocked Modulation256 QAM256 QAM256 QAM256 QAM256 QAM Symbol Rate5.360537 Msym/sec5.360537 Msym/sec5.360537 Msym/sec5.360537 Msym/sec5.360537 Msym/sec Downstream Power 2.2 dBmV 3.8 dBmV 3.0 dBmV 2.9 dBmV 2.9 dBmV SNR41.2 dBmV40.8 dBmV40.5 dBmV40.9 dBmV41.0 dBmV Upstream Channel Upstream Frequency36000000 Hz29400000 Hz22800000 Hz0 Hz Lock StatusLockedLockedLockedNot Locked ModulationATDMAATDMAATDMAUnknown Symbol Rate5120 sym/sec5120 sym/sec5120 sym/sec0 sym/sec Upstream Power46.2 dBmV46.2 dBmV46.2 dBmV0 dBmV --- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9013ms rtt min/avg/max/mdev = 23.066/27.049/35.627/4.825 ms Not working: Downstream Channel Downstream Frequency525000000 Hz561000000 Hz567000000 Hz573000000 Hz579000000 Hz Lock StatusLockedLockedLockedLockedLocked Modulation256 QAM256 QAM256 QAM256 QAM256 QAM Symbol Rate5.360537 Msym/sec5.360537 Msym/sec5.360537 Msym/sec5.360537 Msym/sec5.360537 Msym/sec Downstream Power 2.2 dBmV 3.8 dBmV 2.9 dBmV 2.8 dBmV 2.9 dBmV SNR41.4 dBmV40.8 dBmV40.4 dBmV41.0 dBmV41.3 dBmV Upstream Channel Upstream Frequency36000000 Hz29400000 Hz22800000 Hz0 Hz Lock StatusLockedLockedLockedNot Locked ModulationATDMAATDMAATDMAUnknown Symbol Rate5120 sym/sec5120 sym/sec5120 sym/sec0 sym/sec Upstream Power46.5 dBmV46.5 dBmV46.5 dBmV0 dBmV --- 8.8.8.8 ping statistics --- 233 packets transmitted, 232 received, 0% packet loss, time 232884ms rtt min/avg/max/mdev = 23.431/1918.702/8758.161/2017.033 ms, pipe 9 I'm not seeing any big difference in SNR (and only slight differences in upstream power) and everything else seems to be the same. Though, since db is logarithmic, .3 might be enough to matter? On Thu, Feb 20, 2014 at 4:14 PM, Dan Shoop wrote: > > On Feb 20, 2014, at 4:08 AM, shawn wilson wrote: > >> A while ago I got Comcast's business service. Semi-idle connections >> are get dropped (I haven't really diagnosed this - I just no that it >> isn't the client or server but some network in between). However the >> second and most obvious issue is that intermittently, the service will >> grind to a halt: >> --- 8.8.8.8 ping statistics --- >> 37 packets transmitted, 34 received, 8% packet loss, time 36263ms >> rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe 15 >> >> After a modem reboot, it goes normal: >> --- 8.8.8.8 ping statistics --- >> 4 packets transmitted, 4 received, 0% packet loss, time 3003ms >> rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms >> >> This seems to happen about once or twice a day. I can't attribute it >> to any type of traffic or number of connections. All of the rest of >> the network equipment is the same and the behavior persists when a >> computer is plugged directly into the modem. I called Comcast and they >> said they didn't see anything even when I was experiencing ridiculous >> ping times. I tend to think it's an issue with the 'modem' but I'm not >> sure what the issue might be or how to reproduce it when asked to if I >> tell them to look at it. > > I?ve seen this happen before with various cable ISPs. I?d concur with the poster suggesting intermittent noise on the cable segment as a likely culprit. Also if you have a cable modem that binds multiple channels for higher bandwidth this can also be problematic, especially with the noise. Signals will look good to the NOC but it?s not the signal ?level" that?s the issue it?s the signal to noise level. Noise has to be measured locally and techs don?t always check SNL. > > Also check to see if the packets aren?t actually being dropped but just taking longer than ping is looking for. Also check for out of sequence packets returned. These can indicate flapping of a bonded circuit or the bonded circuit experiencing noise. Try seeing if you disconnect everything and get a straight run to the demarc, with a know and tested out good cable, if the problem doesn?t ever occur. This could indicate noise on the cable in your premise. But I?ve experienced this same problem with noise coming through the demarc. I?ve also seen levels too hot beyond the demarc causing similar problems too. > > HTH. > > > -d > > ----- > > Dan Shoop > shoop at iwiring.net > 1-646-402-5293 (GoogleVoice) > > > > From refresh.lsong at gmail.com Fri Feb 21 11:57:45 2014 From: refresh.lsong at gmail.com (Song Li) Date: Fri, 21 Feb 2014 19:57:45 +0800 Subject: question about AS relationship In-Reply-To: <201402211113.23856.mark.tinka@seacom.mu> References: <5305B983.1080406@gmail.com> <5306F8C3.8070400@gmail.com> <201402211113.23856.mark.tinka@seacom.mu> Message-ID: <53073F39.5070805@gmail.com> Thanks. I'm doing some research on route leaks, you are a great help to me. Sky li > On Friday, February 21, 2014 08:57:07 AM Song Li wrote: > >> the AS relationship between AS1 and AS2/3 is peer, and >> AS1 cannot announce routes from AS3 to provider1 by >> rule. > > Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in > general best practice filtering rules, unless transit is > requested. > >> But if AS1 do it, and the realtionship between AS1 >> and AS3 is invisible to provider1, how can provider1 >> detect this route leak without knowing the privacy? > > Provider-1 wouldn't care whether it's a route leak or not. > In Provider-1's mind, Peer-AS3 could (suddenly) be a > customer of AS1. And since AS1 is a customer of Provider-1, > Provider-1 will be happy to move those packets along as it > represents more revenue for Provider-1 (more so if traffic > is sold on a 95th percentile or volume utilization basis). > > It is, really, up to AS3 to detect that AS1 has leaked its > routes (or paths, to be precise) to Provider-1, and then > pick up the phone and scream at AS1 to get that leak fixed > plugged. > > Of course, all of this is a moot point if Provider-1 is a > good provider and makes sure they only accept routes and > paths from AS3 that AS3 should be sending to Provider-1 in > the first place. But as we know, some providers are a bit > (actually, very) lazy here. > >> In other words, could the business relationship between >> AS1 and AS3 be known to provider1/2? > > Not really (or not that easily, to be specific). > > With enough time and access to several looking glasses and > public route servers, one could "infer" (to a certain degree > of error) business relationships between peering > relationships, i.e., whether they relationships are > customer, peer or provider. > > But in your particular case, unless AS3 has a direct > connection toward Provider-1/2 (where a route leak would > introduce more problems), Provider-1/2 don't really care > about whether this is a leak or not from AS1. > > But again, this whole discussion is mooted if Provider-1/2 > do proper background checks and filtering before they turn- > up the service for AS1. > > Mark. > -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From rwebb at ropeguru.com Fri Feb 21 12:12:00 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Fri, 21 Feb 2014 07:12:00 -0500 Subject: comcast business service In-Reply-To: References: Message-ID: Biggest unknown at this point is your upstream SNR. If there is noise ingress somewhere in the plant, then your upstream could be having all kinds of issues. Robert On Fri, 21 Feb 2014 05:23:07 -0500 shawn wilson wrote: > Works: > > Downstream Channel > Downstream Frequency525000000 Hz561000000 Hz567000000 Hz573000000 >Hz579000000 Hz > Lock StatusLockedLockedLockedLockedLocked > Modulation256 QAM256 QAM256 QAM256 QAM256 QAM > Symbol Rate5.360537 Msym/sec5.360537 Msym/sec5.360537 >Msym/sec5.360537 > Msym/sec5.360537 Msym/sec > Downstream Power 2.2 dBmV 3.8 dBmV 3.0 dBmV 2.9 dBmV 2.9 dBmV > SNR41.2 dBmV40.8 dBmV40.5 dBmV40.9 dBmV41.0 dBmV > Upstream Channel > Upstream Frequency36000000 Hz29400000 Hz22800000 Hz0 Hz > Lock StatusLockedLockedLockedNot Locked > ModulationATDMAATDMAATDMAUnknown > Symbol Rate5120 sym/sec5120 sym/sec5120 sym/sec0 sym/sec > Upstream Power46.2 dBmV46.2 dBmV46.2 dBmV0 dBmV > > --- 8.8.8.8 ping statistics --- > 10 packets transmitted, 10 received, 0% packet loss, time 9013ms > rtt min/avg/max/mdev = 23.066/27.049/35.627/4.825 ms > > Not working: > > Downstream Channel > Downstream Frequency525000000 Hz561000000 Hz567000000 Hz573000000 >Hz579000000 Hz > Lock StatusLockedLockedLockedLockedLocked > Modulation256 QAM256 QAM256 QAM256 QAM256 QAM > Symbol Rate5.360537 Msym/sec5.360537 Msym/sec5.360537 >Msym/sec5.360537 > Msym/sec5.360537 Msym/sec > Downstream Power 2.2 dBmV 3.8 dBmV 2.9 dBmV 2.8 dBmV 2.9 dBmV > SNR41.4 dBmV40.8 dBmV40.4 dBmV41.0 dBmV41.3 dBmV > Upstream Channel > Upstream Frequency36000000 Hz29400000 Hz22800000 Hz0 Hz > Lock StatusLockedLockedLockedNot Locked > ModulationATDMAATDMAATDMAUnknown > Symbol Rate5120 sym/sec5120 sym/sec5120 sym/sec0 sym/sec > Upstream Power46.5 dBmV46.5 dBmV46.5 dBmV0 dBmV > > --- 8.8.8.8 ping statistics --- > 233 packets transmitted, 232 received, 0% packet loss, time 232884ms > rtt min/avg/max/mdev = 23.431/1918.702/8758.161/2017.033 ms, pipe 9 > > I'm not seeing any big difference in SNR (and only slight >differences > in upstream power) and everything else seems to be the same. Though, > since db is logarithmic, .3 might be enough to matter? > > On Thu, Feb 20, 2014 at 4:14 PM, Dan Shoop >wrote: >> >> On Feb 20, 2014, at 4:08 AM, shawn wilson >>wrote: >> >>> A while ago I got Comcast's business service. Semi-idle connections >>> are get dropped (I haven't really diagnosed this - I just no that it >>> isn't the client or server but some network in between). However the >>> second and most obvious issue is that intermittently, the service >>>will >>> grind to a halt: >>> --- 8.8.8.8 ping statistics --- >>> 37 packets transmitted, 34 received, 8% packet loss, time 36263ms >>> rtt min/avg/max/mdev = 398.821/5989.160/14407.055/3808.068 ms, pipe >>>15 >>> >>> After a modem reboot, it goes normal: >>> --- 8.8.8.8 ping statistics --- >>> 4 packets transmitted, 4 received, 0% packet loss, time 3003ms >>> rtt min/avg/max/mdev = 23.181/23.920/24.298/0.474 ms >>> >>> This seems to happen about once or twice a day. I can't attribute it >>> to any type of traffic or number of connections. All of the rest of >>> the network equipment is the same and the behavior persists when a >>> computer is plugged directly into the modem. I called Comcast and >>>they >>> said they didn't see anything even when I was experiencing >>>ridiculous >>> ping times. I tend to think it's an issue with the 'modem' but I'm >>>not >>> sure what the issue might be or how to reproduce it when asked to if >>>I >>> tell them to look at it. >> >> I?ve seen this happen before with various cable ISPs. I?d concur >>with the poster suggesting intermittent noise on the cable segment as >>a likely culprit. Also if you have a cable modem that binds multiple >>channels for higher bandwidth this can also be problematic, >>especially with the noise. Signals will look good to the NOC but it?s >>not the signal ?level" that?s the issue it?s the signal to noise >>level. Noise has to be measured locally and techs don?t always check >>SNL. >> >> Also check to see if the packets aren?t actually being dropped but >>just taking longer than ping is looking for. Also check for out of >>sequence packets returned. These can indicate flapping of a bonded >>circuit or the bonded circuit experiencing noise. Try seeing if you >>disconnect everything and get a straight run to the demarc, with a >>know and tested out good cable, if the problem doesn?t ever occur. >>This could indicate noise on the cable in your premise. But I?ve >>experienced this same problem with noise coming through the demarc. >>I?ve also seen levels too hot beyond the demarc causing similar >>problems too. >> >> HTH. >> >> >> -d >> >> ----- >> >> Dan Shoop >> shoop at iwiring.net >> 1-646-402-5293 (GoogleVoice) >> >> >> >> > From gourmetcisco at hotmail.com Fri Feb 21 14:39:21 2014 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Fri, 21 Feb 2014 09:39:21 -0500 Subject: out of band management gear Message-ID: Hi folks, I wonder if anyone has good experiences to share with out-of-band hardware? I'm looking for a good OOB hardware vendor. I need to manage my routers/switches/firewalls in a datacenter located overseas, and I'm looking to setup a good serial console server via an OOB link. I've been looking at Lantronix, OpenGear, Raritan...but they all seem to have the same basic features. I'm having trouble really differentiating them. I'm interested in analog modem, cellular options for my OOB link. Or even a secondary internet circuit either wired or wifi if the DC has that option available. Any good suggestions or experiences with a current OOB solution out there? What are you doing for your OOB management? thanks,Hank From jcurran at arin.net Fri Feb 21 14:40:19 2014 From: jcurran at arin.net (John Curran) Date: Fri, 21 Feb 2014 14:40:19 +0000 Subject: Networking folk in the San Diego area... Message-ID: <849B84CB-BDE7-474E-AFC2-1669ED68C760@arin.net> NANOGers - Just a reminder that there is a ARIN+NANOG on the Road session taking place in San Diego next week; the day long program has NANOG and ARIN speakers and is free but advance registration is recommended. If you know anyone who might benefit from attending such an event, please bring it to their attention! For more information, see Betty's announcement here: Thanks! /John John Curran President and CEO ARIN From dhubbard at dino.hostasaurus.com Fri Feb 21 14:49:40 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 21 Feb 2014 09:49:40 -0500 Subject: out of band management gear References: Message-ID: Opengear's stuff works great; I believe they have models that support modem on serial port to complement the built-in cell connection. I really like the cell stuff; you can have the device keep the data side of the cell interface down for security and send it a text message to bring it hot so you can ssh in. It supports key-based auth, firewalling, you can chain a serial hub to it if you need a whole bunch of ports, you can map ssh ports to serial ports so you can just ssh directly to the device you need to talk to, etc. On the newer devices, and this is not 'officially supported' but you can do it yourself or even pay them to do it, you can set the different Ethernet ports on the device to different subnets, or even do vlan tagging since it's all just linux when it comes down to it. We use their ACM5500 series to get cell-based out of band for our serial devices and also stick it on four different vlans so that it can get to things that require network-based management even if there's a routing issue. If you're in a noisy data center, or one that has thick walls, I've found a high gain antenna makes a world of difference, but takes some playing around with the web interface to watch your signal levels while you turn the antenna to find the strongest tower to point it in the direction of. David -----Original Message----- From: Hank Disuko [mailto:gourmetcisco at hotmail.com] Sent: Friday, February 21, 2014 9:39 AM To: NANOG Subject: out of band management gear Hi folks, I wonder if anyone has good experiences to share with out-of-band hardware? I'm looking for a good OOB hardware vendor. I need to manage my routers/switches/firewalls in a datacenter located overseas, and I'm looking to setup a good serial console server via an OOB link. I've been looking at Lantronix, OpenGear, Raritan...but they all seem to have the same basic features. I'm having trouble really differentiating them. I'm interested in analog modem, cellular options for my OOB link. Or even a secondary internet circuit either wired or wifi if the DC has that option available. Any good suggestions or experiences with a current OOB solution out there? What are you doing for your OOB management? thanks,Hank From jmkeller at houseofzen.org Fri Feb 21 15:09:48 2014 From: jmkeller at houseofzen.org (James Michael Keller) Date: Fri, 21 Feb 2014 10:09:48 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: References: Message-ID: <53076C3C.50401@houseofzen.org> On 02/20/2014 10:08 AM, Nick Cameo wrote: > Hello Everyone, > > According to mtr command we are consistently seeing > level3_bx4-montrealak.net > dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get > this resolved are greatly appreciated. > > > HOST: victoria Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.2.1 0.0% 10 0.5 0.8 0.4 1.6 0.5 > 2.|-- lns2-montrealak_lo0_LNS.n 0.0% 10 6.7 7.6 6.7 8.8 0.7 > 3.|-- agg1-montrealak_GE0-2-2_1 0.0% 10 6.4 6.3 5.4 7.6 0.6 > 4.|-- bx4-montrealak_so-0-0-0.n 0.0% 10 6.0 5.8 4.9 7.0 0.7 > 5.|-- level3_bx4-montrealak.net 50.0% 10 6.5 6.7 5.7 7.9 0.8 > 6.|-- ae-11-11.car1.Montreal2.L 0.0% 10 92.2 91.7 91.0 92.8 0.7 > 7.|-- ae-5-5.ebr2.NewYork1.Leve 0.0% 10 90.9 92.0 90.9 92.7 0.6 > > > Kind Regards, > > Nick. > I you do not see as high or higher packet loss reported at the hops after, all you are seeing is control plane filtering / rate limiting on that router. -- -James From symack at gmail.com Fri Feb 21 15:16:35 2014 From: symack at gmail.com (Nick Cameo) Date: Fri, 21 Feb 2014 10:16:35 -0500 Subject: level3_bx4-montrealak.net consistently dropping 50% of the packets In-Reply-To: <53076C3C.50401@houseofzen.org> References: <53076C3C.50401@houseofzen.org> Message-ID: Thank you all for clarifying. Really appreciate it. From bryan at digitalocean.com Fri Feb 21 15:39:20 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 21 Feb 2014 10:39:20 -0500 Subject: out of band management gear In-Reply-To: References: Message-ID: We have both lantronix and opengear hardware and use the og brand almost exclusively now. Good price, extremely reliable. We have about 200 of them. On Feb 21, 2014 9:41 AM, "Hank Disuko" wrote: > Hi folks, > I wonder if anyone has good experiences to share with out-of-band hardware? > I'm looking for a good OOB hardware vendor. I need to manage my > routers/switches/firewalls in a datacenter located overseas, and I'm > looking to setup a good serial console server via an OOB link. > I've been looking at Lantronix, OpenGear, Raritan...but they all seem to > have the same basic features. I'm having trouble really differentiating > them. > I'm interested in analog modem, cellular options for my OOB link. Or even > a secondary internet circuit either wired or wifi if the DC has that option > available. > Any good suggestions or experiences with a current OOB solution out there? > What are you doing for your OOB management? > thanks,Hank From bill at herrin.us Fri Feb 21 16:15:49 2014 From: bill at herrin.us (William Herrin) Date: Fri, 21 Feb 2014 11:15:49 -0500 Subject: comcast business service In-Reply-To: References: Message-ID: On Fri, Feb 21, 2014 at 5:23 AM, shawn wilson wrote: > I'm not seeing any big difference in SNR (and only slight differences > in upstream power) and everything else seems to be the same. Though, > since db is logarithmic, .3 might be enough to matter? Do you also receive an _analog_ television signal from Comcast? How's the picture? Any ghosting, blurring or white noise? Any difference between working times and non-working times for your Internet service? Any difference if you connect directly to their entry cable without allowing it to touch the cable in your facility? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kenneth.mcrae at me.com Fri Feb 21 16:25:19 2014 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Fri, 21 Feb 2014 08:25:19 -0800 Subject: out of band management gear In-Reply-To: References: Message-ID: <6C83ABBC-249C-4657-BE84-C6FB53272461@me.com> Using open gear exclusively now...no real issues with it. Sent from my iPad > On Feb 21, 2014, at 6:39 AM, Hank Disuko wrote: > > Hi folks, > I wonder if anyone has good experiences to share with out-of-band hardware? > I'm looking for a good OOB hardware vendor. I need to manage my routers/switches/firewalls in a datacenter located overseas, and I'm looking to setup a good serial console server via an OOB link. > I've been looking at Lantronix, OpenGear, Raritan...but they all seem to have the same basic features. I'm having trouble really differentiating them. > I'm interested in analog modem, cellular options for my OOB link. Or even a secondary internet circuit either wired or wifi if the DC has that option available. > Any good suggestions or experiences with a current OOB solution out there? What are you doing for your OOB management? > thanks,Hank From brian at aereo.com Fri Feb 21 17:16:44 2014 From: brian at aereo.com (Brian Loveland) Date: Fri, 21 Feb 2014 11:16:44 -0600 Subject: out of band management gear In-Reply-To: <6C83ABBC-249C-4657-BE84-C6FB53272461@me.com> References: <6C83ABBC-249C-4657-BE84-C6FB53272461@me.com> Message-ID: Same here, dozens of opengear devices deployed, about half with cellular, only issue we ever had 1 DOA (not totally dead, but behaving really badly) unit and they sent an overnight replacement since we were on the road visiting a remote site. On Fri, Feb 21, 2014 at 10:25 AM, Kenneth McRae wrote: > Using open gear exclusively now...no real issues with it. > > Sent from my iPad > > > On Feb 21, 2014, at 6:39 AM, Hank Disuko > wrote: > > > > Hi folks, > > I wonder if anyone has good experiences to share with out-of-band > hardware? > > I'm looking for a good OOB hardware vendor. I need to manage my > routers/switches/firewalls in a datacenter located overseas, and I'm > looking to setup a good serial console server via an OOB link. > > I've been looking at Lantronix, OpenGear, Raritan...but they all seem to > have the same basic features. I'm having trouble really differentiating > them. > > I'm interested in analog modem, cellular options for my OOB link. Or > even a secondary internet circuit either wired or wifi if the DC has that > option available. > > Any good suggestions or experiences with a current OOB solution out > there? What are you doing for your OOB management? > > thanks,Hank > > From phil.gardnerjr at gmail.com Fri Feb 21 17:37:21 2014 From: phil.gardnerjr at gmail.com (Phil Gardner) Date: Fri, 21 Feb 2014 12:37:21 -0500 Subject: VMware Training In-Reply-To: <5304F493.4040106@gmail.com> References: <5304F493.4040106@gmail.com> Message-ID: <53078ED1.4020802@gmail.com> On 02/19/2014 01:14 PM, Phil Gardner wrote: > Not sure if this list is the best place, but it is probably the only > list that I'm on that won't give me a bunch of grief about the chosen > technology. > > I looked at VMware's site, and there are a ton of options. I'm wondering > if anyone has some basic suggestions or experiences. > > I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm > sufficiently versed in deploying scripted ESXi (including 5.x) > installations for a specific environment, including vswitches/SAN config > (but only with NFS datastores backed by a NetApp, unfortunately, no > blockbased stores). > > I'd like to get experience deploying VCenter clusters, down to DRS/HA > config, other block based storage, and anything else a large environment > needs. > > Thoughts or experiences? > Thanks for the responses everyone. I will be petitioning my manager for the vShpere: Install, Configure, Manage v5.5 course. My homelab currently consists of a custom dual opteron box with lots of disk, an HP P2000, and a massive CoRAID array. Looks like I'll have to scrounge up a couple other hosts for ESXi since my custom system is running CentOS, and ESXi under KVM still looks like a no-go. -- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538 From eugen at imacandi.net Fri Feb 21 17:44:52 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 21 Feb 2014 19:44:52 +0200 Subject: VMware Training In-Reply-To: <53078ED1.4020802@gmail.com> References: <5304F493.4040106@gmail.com> <53078ED1.4020802@gmail.com> Message-ID: On Fri, Feb 21, 2014 at 7:37 PM, Phil Gardner wrote: > On 02/19/2014 01:14 PM, Phil Gardner wrote: > >> Not sure if this list is the best place, but it is probably the only >> list that I'm on that won't give me a bunch of grief about the chosen >> technology. >> >> I looked at VMware's site, and there are a ton of options. I'm wondering >> if anyone has some basic suggestions or experiences. >> >> I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm >> sufficiently versed in deploying scripted ESXi (including 5.x) >> installations for a specific environment, including vswitches/SAN config >> (but only with NFS datastores backed by a NetApp, unfortunately, no >> blockbased stores). >> >> I'd like to get experience deploying VCenter clusters, down to DRS/HA >> config, other block based storage, and anything else a large environment >> needs. >> >> Thoughts or experiences? >> >> > Thanks for the responses everyone. I will be petitioning my manager for > the vShpere: Install, Configure, Manage v5.5 course. > As a note to this, if you get it approved, make sure that the trainer has (a lot of) real life experience implementing vSphere. It makes a big difference when you run into trouble with the labs or when you have questions that are related to best practices. Eugeniu From cscora at apnic.net Fri Feb 21 18:11:58 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Feb 2014 04:11:58 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201402211811.s1LIBw3r005590@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Feb, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 483198 Prefixes after maximum aggregation: 191729 Deaggregation factor: 2.52 Unique aggregates announced to Internet: 239336 Total ASes present in the Internet Routing Table: 46226 Prefixes per ASN: 10.45 Origin-only ASes present in the Internet Routing Table: 35611 Origin ASes announcing only one prefix: 16405 Transit ASes present in the Internet Routing Table: 6049 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1881 Unregistered ASNs in the Routing Table: 488 Number of 32-bit ASNs allocated by the RIRs: 5975 Number of 32-bit ASNs visible in the Routing Table: 4566 Prefixes from 32-bit ASNs in the Routing Table: 14720 Number of bogon 32-bit ASNs visible in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 435 Number of addresses announced to Internet: 2657187844 Equivalent to 158 /8s, 97 /16s and 120 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.8 Total number of prefixes smaller than registry allocations: 168859 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 114566 Total APNIC prefixes after maximum aggregation: 34472 APNIC Deaggregation factor: 3.32 Prefixes being announced from the APNIC address blocks: 117125 Unique aggregates announced from the APNIC address blocks: 49266 APNIC Region origin ASes present in the Internet Routing Table: 4889 APNIC Prefixes per ASN: 23.96 APNIC Region origin ASes announcing only one prefix: 1225 APNIC Region transit ASes present in the Internet Routing Table: 849 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 843 Number of APNIC addresses announced to Internet: 731163776 Equivalent to 43 /8s, 148 /16s and 172 /24s Percentage of available APNIC address space announced: 85.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 165378 Total ARIN prefixes after maximum aggregation: 82750 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 166722 Unique aggregates announced from the ARIN address blocks: 77354 ARIN Region origin ASes present in the Internet Routing Table: 16154 ARIN Prefixes per ASN: 10.32 ARIN Region origin ASes announcing only one prefix: 6109 ARIN Region transit ASes present in the Internet Routing Table: 1679 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 66 Number of ARIN addresses announced to Internet: 1066115712 Equivalent to 63 /8s, 139 /16s and 162 /24s Percentage of available ARIN address space announced: 56.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 122196 Total RIPE prefixes after maximum aggregation: 61905 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 126208 Unique aggregates announced from the RIPE address blocks: 80452 RIPE Region origin ASes present in the Internet Routing Table: 17650 RIPE Prefixes per ASN: 7.15 RIPE Region origin ASes announcing only one prefix: 8321 RIPE Region transit ASes present in the Internet Routing Table: 2874 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2631 Number of RIPE addresses announced to Internet: 656485252 Equivalent to 39 /8s, 33 /16s and 43 /24s Percentage of available RIPE address space announced: 95.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 54382 Total LACNIC prefixes after maximum aggregation: 9946 LACNIC Deaggregation factor: 5.47 Prefixes being announced from the LACNIC address blocks: 60169 Unique aggregates announced from the LACNIC address blocks: 27789 LACNIC Region origin ASes present in the Internet Routing Table: 2072 LACNIC Prefixes per ASN: 29.04 LACNIC Region origin ASes announcing only one prefix: 550 LACNIC Region transit ASes present in the Internet Routing Table: 419 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1016 Number of LACNIC addresses announced to Internet: 151669120 Equivalent to 9 /8s, 10 /16s and 73 /24s Percentage of available LACNIC address space announced: 90.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11838 Total AfriNIC prefixes after maximum aggregation: 2618 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 12539 Unique aggregates announced from the AfriNIC address blocks: 4114 AfriNIC Region origin ASes present in the Internet Routing Table: 696 AfriNIC Prefixes per ASN: 18.02 AfriNIC Region origin ASes announcing only one prefix: 200 AfriNIC Region transit ASes present in the Internet Routing Table: 145 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 10 Number of AfriNIC addresses announced to Internet: 51426816 Equivalent to 3 /8s, 16 /16s and 182 /24s Percentage of available AfriNIC address space announced: 51.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2983 11564 891 Korea Telecom 17974 2752 902 88 PT Telekomunikasi Indonesia 7545 2187 320 117 TPG Telecom Limited 4755 1837 396 197 TATA Communications formerly 9829 1504 1282 41 National Internet Backbone 9583 1304 102 534 Sify Limited 7552 1231 1082 13 Viettel Corporation 9498 1226 309 69 BHARTI Airtel Ltd. 4808 1169 2116 354 CNCGROUP IP network China169 24560 1106 376 172 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3023 3688 53 BellSouth.net Inc. 22773 2323 2938 139 Cox Communications Inc. 1785 2164 691 130 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1692 1673 576 Charter Communications 4323 1619 1089 411 tw telecom holdings, inc. 701 1496 11175 767 MCI Communications Services, 30036 1377 297 564 Mediacom Communications Corp 6983 1300 772 581 ITC^Deltacom 7018 1291 18003 836 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1814 544 16 OJSC "Vimpelcom" 34984 1403 243 225 TELLCOM ILETISIM HIZMETLERI A 20940 1227 453 922 Akamai International B.V. 13188 1048 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 893 370 41 Bezeq International-Ltd 6849 860 362 37 JSC "Ukrtelecom" 6830 773 2331 424 Liberty Global Operations B.V 12479 714 800 50 France Telecom Espana SA 35819 563 634 74 Bayanat Al-Oula For Network S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3485 1903 91 NET Servi?os de Comunica??o S 10620 2749 440 199 Telmex Colombia S.A. 18881 1901 972 21 Global Village Telecom 7303 1740 1170 219 Telecom Argentina S.A. 8151 1380 2900 419 Uninet S.A. de C.V. 6503 932 434 61 Axtel, S.A.B. de C.V. 11830 869 364 15 Instituto Costarricense de El 27947 847 101 88 Telconet S.A 7738 845 1626 38 Telemar Norte Leste S.A. 3816 779 314 125 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1630 240 6 Sudanese Mobile Telephone (ZA 24863 917 380 28 Link Egypt (Link.NET) 6713 602 685 28 Office National des Postes et 8452 487 958 13 TE-AS 24835 298 144 9 Vodafone Data 36992 264 783 24 ETISALAT MISR 29571 248 22 17 Cote d'Ivoire Telecom 3741 247 921 208 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3485 1903 91 NET Servi?os de Comunica??o S 6389 3023 3688 53 BellSouth.net Inc. 4766 2983 11564 891 Korea Telecom 17974 2752 902 88 PT Telekomunikasi Indonesia 10620 2749 440 199 Telmex Colombia S.A. 22773 2323 2938 139 Cox Communications Inc. 7545 2187 320 117 TPG Telecom Limited 1785 2164 691 130 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1901 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3023 2970 BellSouth.net Inc. 17974 2752 2664 PT Telekomunikasi Indonesia 10620 2749 2550 Telmex Colombia S.A. 22773 2323 2184 Cox Communications Inc. 4766 2983 2092 Korea Telecom 7545 2187 2070 TPG Telecom Limited 1785 2164 2034 PaeTec Communications, Inc. 18881 1901 1880 Global Village Telecom 18566 2048 1870 MegaPath Corporation 8402 1814 1798 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 41.73.18.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:30 /11:90 /12:255 /13:476 /14:952 /15:1651 /16:12850 /17:6753 /18:11477 /19:23687 /20:33381 /21:36211 /22:51727 /23:45050 /24:256348 /25:794 /26:952 /27:438 /28:12 /29:17 /30:7 /31:1 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 6389 1696 3023 BellSouth.net Inc. 36998 1599 1630 Sudanese Mobile Telephone (ZA 22773 1565 2323 Cox Communications Inc. 8402 1496 1814 OJSC "Vimpelcom" 30036 1215 1377 Mediacom Communications Corp 11492 1165 1203 CABLE ONE, INC. 1785 1160 2164 PaeTec Communications, Inc. 6983 1040 1300 ITC^Deltacom 22561 990 1276 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:932 2:809 3:3 4:16 5:901 6:19 8:656 12:1850 13:3 14:956 15:9 16:3 17:24 18:21 20:35 23:683 24:1715 27:1750 31:1578 32:44 33:2 34:5 36:118 37:1933 38:930 39:4 40:191 41:3082 42:243 44:18 46:2120 47:13 49:675 50:921 52:12 54:56 55:5 57:26 58:1149 59:593 60:372 61:1525 62:1249 63:1966 64:4371 65:2248 66:4192 67:2063 68:1024 69:3304 70:853 71:468 72:1999 74:2667 75:310 76:311 77:1216 78:1044 79:693 80:1295 81:1124 82:665 83:742 84:761 85:1242 86:449 87:1064 88:518 89:1740 90:151 91:5716 92:667 93:1679 94:2027 95:1475 96:535 97:352 98:1070 99:41 100:34 101:781 103:4219 105:535 106:164 107:482 108:542 109:2099 110:981 111:1253 112:618 113:829 114:790 115:1074 116:1033 117:872 118:1267 119:1307 120:341 121:789 122:1914 123:1257 124:1419 125:1450 128:642 129:245 130:360 131:659 132:356 133:157 134:312 135:74 136:249 137:300 138:348 139:157 140:206 141:359 142:553 143:418 144:504 145:98 146:599 147:446 148:791 149:345 150:150 151:600 152:421 153:204 154:86 155:524 156:325 157:367 158:293 159:865 160:356 161:474 162:1154 163:218 164:677 165:609 166:278 167:593 168:1048 169:124 170:1183 171:196 172:16 173:1590 174:679 175:589 176:1451 177:2788 178:1979 179:469 180:1624 181:974 182:1434 183:496 184:697 185:1299 186:2826 187:1452 188:1988 189:1276 190:7443 191:103 192:7102 193:5455 194:4014 195:3368 196:1365 197:1107 198:4918 199:5585 200:6064 201:2561 202:8968 203:8872 204:4482 205:2663 206:2933 207:2882 208:3965 209:3673 210:3092 211:1697 212:2210 213:2030 214:877 215:84 216:5508 217:1709 218:567 219:322 220:1289 221:595 222:336 223:618 End of report From contact at winterei.se Fri Feb 21 15:44:34 2014 From: contact at winterei.se (Paul S.) Date: Sat, 22 Feb 2014 00:44:34 +0900 Subject: out of band management gear In-Reply-To: References: Message-ID: <53077462.9050101@winterei.se> Lantronix is pretty solid if it doesn't have issues with your hardware. I have a bunch of older Dell boxes where turning on virtual media makes them stall indefinitely on the boot prompt. Though, for serial only stuff -- it should be pretty good. On 2/22/2014 ?? 12:39, Bryan Socha wrote: > We have both lantronix and opengear hardware and use the og brand almost > exclusively now. Good price, extremely reliable. We have about 200 of > them. > On Feb 21, 2014 9:41 AM, "Hank Disuko" wrote: > >> Hi folks, >> I wonder if anyone has good experiences to share with out-of-band hardware? >> I'm looking for a good OOB hardware vendor. I need to manage my >> routers/switches/firewalls in a datacenter located overseas, and I'm >> looking to setup a good serial console server via an OOB link. >> I've been looking at Lantronix, OpenGear, Raritan...but they all seem to >> have the same basic features. I'm having trouble really differentiating >> them. >> I'm interested in analog modem, cellular options for my OOB link. Or even >> a secondary internet circuit either wired or wifi if the DC has that option >> available. >> Any good suggestions or experiences with a current OOB solution out there? >> What are you doing for your OOB management? >> thanks,Hank From kwoody at citywest.ca Fri Feb 21 18:39:11 2014 From: kwoody at citywest.ca (Keith) Date: Fri, 21 Feb 2014 10:39:11 -0800 Subject: Akamai Message-ID: <53079D4F.5080904@citywest.ca> I just want to publicly say hats off to Akamai today. We have seen spikes on our Akamai server before, but nothing like it has been in the last few days with the Canadian hockey live streaming. IOS7 release from Apple spiked it, but today, almost 800 megs of traffic coming off our server currently with the mens US/Canada match up. Tip of the hat to you folks. From clayton at mnsi.net Fri Feb 21 18:47:27 2014 From: clayton at mnsi.net (Clayton Zekelman) Date: Fri, 21 Feb 2014 13:47:27 -0500 Subject: Akamai In-Reply-To: <53079D4F.5080904@citywest.ca> References: <53079D4F.5080904@citywest.ca> Message-ID: <1289517A-9DB1-4F94-AA06-A3BAAB161DA4@mnsi.net> Hats off? They're not even sending the streams through TORIX which seems like a big day FAIL to me. Sent from my iPhone On 2014-02-21, at 1:39 PM, Keith wrote: > I just want to publicly say hats off to Akamai today. > > We have seen spikes on our Akamai server before, but nothing like it has been > in the last few days with the Canadian hockey live streaming. > > IOS7 release from Apple spiked it, but today, almost 800 megs of traffic coming > off our server currently with the mens US/Canada match up. > > Tip of the hat to you folks. > > > > > From kwoody at citywest.ca Fri Feb 21 18:56:34 2014 From: kwoody at citywest.ca (Keith) Date: Fri, 21 Feb 2014 10:56:34 -0800 Subject: Akamai In-Reply-To: <1289517A-9DB1-4F94-AA06-A3BAAB161DA4@mnsi.net> References: <53079D4F.5080904@citywest.ca> <1289517A-9DB1-4F94-AA06-A3BAAB161DA4@mnsi.net> Message-ID: <5307A162.8070605@citywest.ca> I would have figured an IX like that would have something there? Even BCNet has some akamai stuff within their network. We are pretty small in the scheme of things and have had Akamai for quite a few years, but this is the biggest event we have ever seen on our server. On 2/21/2014 10:47 AM, Clayton Zekelman wrote: > Hats off? They're not even sending the streams through TORIX which seems like a big day FAIL to me. > > Sent from my iPhone > > On 2014-02-21, at 1:39 PM, Keith wrote: > >> I just want to publicly say hats off to Akamai today. >> >> We have seen spikes on our Akamai server before, but nothing like it has been >> in the last few days with the Canadian hockey live streaming. >> >> IOS7 release from Apple spiked it, but today, almost 800 megs of traffic coming >> off our server currently with the mens US/Canada match up. >> >> Tip of the hat to you folks. >> >> >> >> >> From clayton at mnsi.net Fri Feb 21 19:12:09 2014 From: clayton at mnsi.net (Clayton Zekelman) Date: Fri, 21 Feb 2014 14:12:09 -0500 Subject: Akamai In-Reply-To: <5307A162.8070605@citywest.ca> References: <53079D4F.5080904@citywest.ca> <1289517A-9DB1-4F94-AA06-A3BAAB161DA4@mnsi.net> <5307A162.8070605@citywest.ca> Message-ID: They have TORIX connections, but they didn't seem to send the stream traffic through them. Sent from my iPhone On 2014-02-21, at 1:56 PM, Keith wrote: > I would have figured an IX like that would have something there? Even BCNet has some akamai stuff > within their network. > > We are pretty small in the scheme of things and have had Akamai for quite a few years, but this is the biggest event we have ever > seen on our server. > > On 2/21/2014 10:47 AM, Clayton Zekelman wrote: >> Hats off? They're not even sending the streams through TORIX which seems like a big day FAIL to me. >> >> Sent from my iPhone >> >> On 2014-02-21, at 1:39 PM, Keith wrote: >> >>> I just want to publicly say hats off to Akamai today. >>> >>> We have seen spikes on our Akamai server before, but nothing like it has been >>> in the last few days with the Canadian hockey live streaming. >>> >>> IOS7 release from Apple spiked it, but today, almost 800 megs of traffic coming >>> off our server currently with the mens US/Canada match up. >>> >>> Tip of the hat to you folks. > > From richard.hesse at weebly.com Fri Feb 21 19:21:39 2014 From: richard.hesse at weebly.com (Richard Hesse) Date: Fri, 21 Feb 2014 19:21:39 +0000 Subject: out of band management gear In-Reply-To: References: Message-ID: We're really pleased with the Perle IOLAN line. They even have a gigabit port without a $10k price tag. Amazing! It really dumbfounds me why so many vendors are still putting 10/100 Ethernet ports on their OOB management (looking at you OpenGear). Especially a PITA today since many switchports today don't support links speeds less than a gigabit. -richard On Fri, Feb 21, 2014 at 2:39 PM, Hank Disuko wrote: > Hi folks, > I wonder if anyone has good experiences to share with out-of-band hardware? > I'm looking for a good OOB hardware vendor. I need to manage my > routers/switches/firewalls in a datacenter located overseas, and I'm > looking to setup a good serial console server via an OOB link. > I've been looking at Lantronix, OpenGear, Raritan...but they all seem to > have the same basic features. I'm having trouble really differentiating > them. > I'm interested in analog modem, cellular options for my OOB link. Or even > a secondary internet circuit either wired or wifi if the DC has that option > available. > Any good suggestions or experiences with a current OOB solution out there? > What are you doing for your OOB management? > thanks,Hank From rcarpen at network1.net Fri Feb 21 20:27:00 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 21 Feb 2014 15:27:00 -0500 (EST) Subject: out of band management gear In-Reply-To: References: Message-ID: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> OpenGear's newer stuff is Gigabit (SFP even). I've not seen any real switch made in the last decade that has a problem with 100Mb/s connections. Ancient cisco, maybe had issues. thanks, -Randy -- Randy Carpenter Vice President - IT Services First Network Group, Inc. (800)578-6381, Opt. 1 http://www.network1.net http://www.facebook.com/FirstNetworkGroup ----- Original Message ----- > We're really pleased with the Perle IOLAN line. They even have a gigabit > port without a $10k price tag. Amazing! > > It really dumbfounds me why so many vendors are still putting 10/100 > Ethernet ports on their OOB management (looking at you OpenGear). > Especially a PITA today since many switchports today don't support links > speeds less than a gigabit. > > -richard > > > On Fri, Feb 21, 2014 at 2:39 PM, Hank Disuko wrote: > > > Hi folks, > > I wonder if anyone has good experiences to share with out-of-band hardware? > > I'm looking for a good OOB hardware vendor. I need to manage my > > routers/switches/firewalls in a datacenter located overseas, and I'm > > looking to setup a good serial console server via an OOB link. > > I've been looking at Lantronix, OpenGear, Raritan...but they all seem to > > have the same basic features. I'm having trouble really differentiating > > them. > > I'm interested in analog modem, cellular options for my OOB link. Or even > > a secondary internet circuit either wired or wifi if the DC has that option > > available. > > Any good suggestions or experiences with a current OOB solution out there? > > What are you doing for your OOB management? > > thanks,Hank > > From hannigan at gmail.com Fri Feb 21 20:39:52 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 21 Feb 2014 15:39:52 -0500 Subject: Akamai In-Reply-To: References: <53079D4F.5080904@citywest.ca> <1289517A-9DB1-4F94-AA06-A3BAAB161DA4@mnsi.net> <5307A162.8070605@citywest.ca> Message-ID: Everyone, We do have an issue at the TorIX. We have isolated it to a hardware bug impacting our networking and we're working to get it fixed ASAP. It's not likely to be entirely fixed prior to the end of the Winter Olympics. We have a workaround that should allow us to serve more traffic locally again. Apologies. Best, -M< (20940) On Fri, Feb 21, 2014 at 2:12 PM, Clayton Zekelman wrote: > They have TORIX connections, but they didn't seem to send the stream traffic through them. > > Sent from my iPhone > > On 2014-02-21, at 1:56 PM, Keith wrote: > >> I would have figured an IX like that would have something there? Even BCNet has some akamai stuff >> within their network. >> >> We are pretty small in the scheme of things and have had Akamai for quite a few years, but this is the biggest event we have ever >> seen on our server. >> >> On 2/21/2014 10:47 AM, Clayton Zekelman wrote: >>> Hats off? They're not even sending the streams through TORIX which seems like a big day FAIL to me. >>> >>> Sent from my iPhone >>> >>> On 2014-02-21, at 1:39 PM, Keith wrote: >>> >>>> I just want to publicly say hats off to Akamai today. >>>> >>>> We have seen spikes on our Akamai server before, but nothing like it has been >>>> in the last few days with the Canadian hockey live streaming. >>>> >>>> IOS7 release from Apple spiked it, but today, almost 800 megs of traffic coming >>>> off our server currently with the mens US/Canada match up. >>>> >>>> Tip of the hat to you folks. >> >> > From brez at brezworks.com Fri Feb 21 21:17:15 2014 From: brez at brezworks.com (Jeremy Bresley) Date: Fri, 21 Feb 2014 15:17:15 -0600 Subject: out of band management gear In-Reply-To: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> Message-ID: <5307C25B.2080605@brezworks.com> On 2/21/2014 2:27 PM, Randy Carpenter wrote: > OpenGear's newer stuff is Gigabit (SFP even). > > I've not seen any real switch made in the last decade that has a problem with 100Mb/s connections. Ancient cisco, maybe had issues. > There's several devices that are 1/10Gb and do NOT support 10/100Mb. Cisco Nexus 5000/5500s, Brocade VDX series stuff, etc. In our new data center, the only 10/100 ports are a couple blades in our Nexus 7018s put there just to provide these lower-speed connections to devices that needed them. Expensive options in a fully loaded chassis just for a couple lower-end devices that could easily justify a couple dollars more to get a Gig PHY instead of the older 100Mb PHY chip. Jeremy "TheBrez" Bresley From cb.list6 at gmail.com Fri Feb 21 21:22:36 2014 From: cb.list6 at gmail.com (Cb B) Date: Fri, 21 Feb 2014 13:22:36 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher wrote: > On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch wrote: >> >> On Feb 20, 2014, at 3:51 PM, John Weekes wrote: >> > On 2/20/2014 12:41 PM, Edward Roels wrote: >> >> Curious if anyone else thinks filtering out NTP packets above a certain >> >> packet size is a good or terrible idea. >> >> >> >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 >> are >> >> typical for a client to successfully synchronize to an NTP server. >> >> >> >> If I query a server for it's list of peers (ntpq -np ) I've seen >> >> packets as large as 522 bytes in a single packet in response to a 54 >> byte >> >> query. I'll admit I'm not 100% clear of the what is happening >> >> protocol-wise when I perform this query. I see there are multiple >> packets >> >> back forth between me and the server depending on the number of peers it >> >> has? >> > >> > If your equipment supports this, and you're seeing reflected NTP >> attacks, then it is an effective stopgap to block nearly all of the inbound >> attack traffic to affected hosts. Some still comes through from NTP servers >> running on nonstandard ports, but not much. >> > > Also, don't forget to ask those sending the attack traffic to trace where > the spoofed packets ingressed their networks. > > > Standard IPv4 NTP response packets are 76 bytes (plus any link-level >> headers), based on my testing. I have been internally filtering packets of >> other sizes against attack targets for some time now with no ill-effect. >> >> You can filter packets that are 440 bytes in size and it will do a lot to >> help the problem, but make sure you conjoin these with protocol udp and >> port=123 rules to avoid collateral damage. >> > > Preferably just source-port 123. > > You may also want to look at filtering UDP/80 outright as well, as that is >> commonly used as an "I'm going to attack port 80" by attackers that don't >> quite understand the difference between UDP and TCP. >> > > Please don't filter UDP/80. It's used by QUIC ( > http://en.wikipedia.org/wiki/QUIC). > > Damian The folks at QUIC have been advised to not use UDP for a new protocol, and they would be very well advised to not use UDP:80 since that is a well known target port used in the DDoS reflection attacks. As Jared noted, UDP:80 is a cesspool today. Attempting to use it for legit traffic is not smart. CB From damian at google.com Fri Feb 21 21:30:05 2014 From: damian at google.com (Damian Menscher) Date: Fri, 21 Feb 2014 13:30:05 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: On Fri, Feb 21, 2014 at 1:22 PM, Cb B wrote: > On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher > wrote: > > On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch > wrote: > > You may also want to look at filtering UDP/80 outright as well, as that > is > >> commonly used as an "I'm going to attack port 80" by attackers that > don't > >> quite understand the difference between UDP and TCP. > > > > Please don't filter UDP/80. It's used by QUIC ( > > http://en.wikipedia.org/wiki/QUIC). > > The folks at QUIC have been advised to not use UDP for a new protocol, > and they would be very well advised to not use UDP:80 since that is a > well known target port used in the DDoS reflection attacks. > Please suggest which protocol has less blocking on the internet today (keeping in mind the full end-to-end stack of CPE, various ISPs, country-level proxies, backbone providers, etc). Damian From cidr-report at potaroo.net Fri Feb 21 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Feb 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201402212200.s1LM01Ni039229@wattle.apnic.net> This report has been generated at Fri Feb 21 21:13:38 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-02-14 493241 277561 15-02-14 494081 277380 16-02-14 493711 277185 17-02-14 493631 277754 18-02-14 494239 277842 19-02-14 494217 276504 20-02-14 490331 276730 21-02-14 490117 276773 AS Summary 46383 Number of ASes in routing system 19017 Number of ASes announcing only one prefix 3478 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A. 119624960 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 21Feb14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 490110 276528 213582 43.6% All ASes AS28573 3478 105 3373 97.0% NET Servi?os de Comunica??o S.A. AS6389 3023 56 2967 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2751 185 2566 93.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2983 900 2083 69.8% KIXS-AS-KR Korea Telecom AS22773 2326 260 2066 88.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18881 1901 25 1876 98.7% Global Village Telecom AS1785 2164 411 1753 81.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 2749 1189 1560 56.7% Telmex Colombia S.A. AS36998 1630 97 1533 94.0% SDN-MOBITEL AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2929 1515 1414 48.3% TWTC - tw telecom holdings, inc. AS7303 1748 449 1299 74.3% Telecom Argentina S.A. AS4755 1837 622 1215 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1256 158 1098 87.4% VIETEL-AS-AP Viettel Corporation AS7545 2190 1123 1067 48.7% TPG-INTERNET-AP TPG Telecom Limited AS22561 1276 227 1049 82.2% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1505 656 849 56.4% BSNL-NIB National Internet Backbone AS18101 993 187 806 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1169 393 776 66.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS35908 870 105 765 87.9% VPLSNET - Krypt Technologies AS24560 1106 373 733 66.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS701 1496 767 729 48.7% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1388 660 728 52.4% Uninet S.A. de C.V. AS6983 1300 581 719 55.3% ITCDELTA - ITC^Deltacom AS4788 974 259 715 73.4% TMNET-AS-AP TM Net, Internet Service Provider AS7738 845 147 698 82.6% Telemar Norte Leste S.A. AS855 751 57 694 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 1029 374 655 63.7% SEEDNET Digital United Inc. AS6147 766 113 653 85.2% Telefonica del Peru S.A.A. AS9808 939 303 636 67.7% CMNET-GD Guangdong Mobile Communication Co.Ltd. Total 51419 12862 38557 75.0% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc. 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.220.176.0/24 AS16265 FIBERRING LeaseWeb B.V. 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.87.0.0/24 AS29571 CITelecom-AS 172.88.0.0/24 AS29571 CITelecom-AS 172.89.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.26.219.0/24 AS38913 ENTER-NET-TEAM-AS Enter-Net Team SRL 193.28.14.0/24 AS34309 LINK11 Link11 GmbH 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.33.252.0/23 AS3356 LEVEL3 Level 3 Communications 193.38.144.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd 193.84.187.0/24 AS16276 OVH OVH Systems 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS 193.111.229.0/24 AS3356 LEVEL3 Level 3 Communications 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.26.0/24 AS16095 JAYNET jay.net a/s 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.121.0/24 AS9143 ZIGGO Ziggo B.V. 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd. 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd. 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd. 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.55.104.0/23 AS7244 ALAMEDANET - Alameda Networks 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB 194.156.179.0/24 AS3209 VODANET Vodafone GmbH 194.176.123.0/24 AS28717 ZENSYSTEMS-AS Zen Systems A/S 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.64.128.0/23 AS8751 MEDIASAT Media Sat SRL 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 FIBERRING LeaseWeb B.V. 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.178.120.0/23 AS39385 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.196.64.0/24 AS26977 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.77.167.0/24 AS22659 208.78.91.0/24 AS19071 MATCHCOM - Match.com, L.L.C. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.164.0/22 AS46099 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.203.80.0/20 AS27021 216.203.80.0/21 AS27021 216.203.87.0/24 AS27021 216.203.88.0/21 AS27021 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 21 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Feb 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201402212200.s1LM02fD039260@wattle.apnic.net> BGP Update Report Interval: 13-Feb-14 -to- 20-Feb-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7315 69280 3.1% 989.7 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 2 - AS60349 59921 2.7% 921.9 -- PBL-KIEV-AS Partners. Business & Law Ltd. 3 - AS34875 58129 2.6% 457.7 -- YANFES OJSC "Rostelecom" 4 - AS9829 44275 2.0% 53.9 -- BSNL-NIB National Internet Backbone 5 - AS28573 32480 1.5% 9.0 -- NET Servi?os de Comunica??o S.A. 6 - AS10620 29235 1.3% 11.1 -- Telmex Colombia S.A. 7 - AS8402 28625 1.3% 35.3 -- CORBINA-AS OJSC "Vimpelcom" 8 - AS41691 21301 1.0% 1183.4 -- SUMTEL-AS-RIPE Summa Telecom LLC 9 - AS13118 20725 0.9% 592.1 -- ASN-YARTELECOM OJSC Rostelecom 10 - AS4775 18183 0.8% 1136.4 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS35181 17214 0.8% 1434.5 -- PWC Autonomous System Number for Public WareHouse Company 12 - AS50710 15128 0.7% 67.2 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 13 - AS7552 14792 0.7% 12.3 -- VIETEL-AS-AP Viettel Corporation 14 - AS8151 14149 0.6% 15.2 -- Uninet S.A. de C.V. 15 - AS7029 12215 0.6% 2.7 -- WINDSTREAM - Windstream Communications Inc 16 - AS9129 11871 0.5% 232.8 -- KE-NET2000 17 - AS45899 11853 0.5% 34.6 -- VNPT-AS-VN VNPT Corp 18 - AS36948 11742 0.5% 5871.0 -- KENIC 19 - AS27738 11645 0.5% 20.2 -- Ecuadortelecom S.A. 20 - AS11976 11552 0.5% 550.1 -- FIDN - Fidelity Communication International Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6459 7616 0.3% 7616.0 -- TRANSBEAM - I-2000, Inc. 2 - AS54465 7038 0.3% 7038.0 -- QPM-AS-1 - QuickPlay Media Inc. 3 - AS36948 11742 0.5% 5871.0 -- KENIC 4 - AS16561 3335 0.1% 3335.0 -- ARIBANETWORK Ariba Inc. Autonomous System 5 - AS36401 3236 0.1% 3236.0 -- SHM-5224 - Information Management 6 - AS38491 3828 0.2% 1914.0 -- BSP-AS-AP Bangko Sentral ng Pilipinas, Manila, Philippines 7 - AS14287 10491 0.5% 1748.5 -- TRIAD-TELECOM - Triad Telecom, Inc. 8 - AS35181 17214 0.8% 1434.5 -- PWC Autonomous System Number for Public WareHouse Company 9 - AS17658 8029 0.4% 1338.2 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 10 - AS43352 1220 0.1% 1220.0 -- TELETEK-CLOUD Teletek Bulut Bilisim ve Iletisim Hizmetleri A.S. 11 - AS41691 21301 1.0% 1183.4 -- SUMTEL-AS-RIPE Summa Telecom LLC 12 - AS4775 18183 0.8% 1136.4 -- GLOBE-TELECOM-AS Globe Telecoms 13 - AS51075 1005 0.1% 1005.0 -- WOLFF-PL WYDAWNICTWO MULTIMEDIALNE KOWALEWSKI I WOLFF SPOLKA CYWILNA PIOTR GLADKI KRZYSZTOF KOWALEWSKI MACIEJ MANSKI 14 - AS7315 69280 3.1% 989.7 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 15 - AS60349 59921 2.7% 921.9 -- PBL-KIEV-AS Partners. Business & Law Ltd. 16 - AS39575 888 0.0% 888.0 -- SIBINTEK-SAMARA-AS Siberian Internet Company 17 - AS57201 847 0.0% 847.0 -- EDF-AS Estonian Defence Forces 18 - AS44153 790 0.0% 790.0 -- SHTE Shirak Technologies LLC 19 - AS3144 2352 0.1% 784.0 -- PINNACLE - Pinnacle On-Line 20 - AS62431 746 0.0% 746.0 -- NCSC-IE-AS National Cyber Security Centre TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 21116 0.9% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 2 - 109.161.64.0/20 20649 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 5 - 195.202.74.0/24 8788 0.4% AS9129 -- KE-NET2000 6 - 85.239.28.0/24 8702 0.4% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 7 - 85.239.24.0/24 8379 0.3% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 8 - 192.58.232.0/24 8161 0.3% AS6629 -- NOAA-AS - NOAA 9 - 113.11.132.0/24 8001 0.3% AS17658 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 10 - 103.11.61.0/24 7791 0.3% AS9387 -- AUGERE-PK AUGERE-Pakistan 11 - 205.247.12.0/24 7616 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 12 - 206.152.15.0/24 7038 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 13 - 67.210.190.0/23 6841 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 14 - 200.23.126.0/24 6680 0.3% AS8151 -- Uninet S.A. de C.V. 15 - 216.109.107.0/24 6671 0.3% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 16 - 198.32.67.0/24 6309 0.3% AS36948 -- KENIC 17 - 196.1.4.0/24 5433 0.2% AS36948 -- KENIC 18 - 67.210.188.0/23 4621 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 19 - 69.38.178.0/24 4122 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 20 - 199.187.118.0/24 4080 0.2% AS11054 -- LIVEPERSON LivePerson, Inc Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From baldur.norddahl at gmail.com Fri Feb 21 22:08:13 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 21 Feb 2014 23:08:13 +0100 Subject: The somewhat illegal fix for NTP attacks Message-ID: Hi The following would probably be illegal so do not actually do this. But what if... there are just 4 billion IPv4 addresses. Scanning that address-space for open NTP is trivially done in a few hours. Abusing these servers for reflection attack is as trivial, hence the problem. How can we get the responsible parties to fix their NTP servers? Answer: DDoS them. With their own service. Or it could be a DDoS defense. As a victim of an ongoing NTP reflection attack, you know exactly the IP-addresses of the vulnerable NTP servers used to attack you. Make them stop by sending back forged NTP packets, so they use up their available bandwidth to DDoS each other instead of you. This could even be automated. If you let them attack their next-hop as discovered by traceroute, it might not even be illegal or harmful. They will only bring down their own link, do no more harm to the internet at large and they can fix it by stopping the NTP service. If they are part of an ongoing DDoS attack it is just self defence to shut them down in the least harmful way possible. Regards, Baldur From landonstewart at gmail.com Fri Feb 21 22:13:24 2014 From: landonstewart at gmail.com (Landon) Date: Fri, 21 Feb 2014 14:13:24 -0800 Subject: The somewhat illegal fix for NTP attacks In-Reply-To: References: Message-ID: On 21 February 2014 14:08, Baldur Norddahl wrote: > Hi > > The following would probably be illegal so do not actually do this. But > what if... there are just 4 billion IPv4 addresses. Scanning that > address-space for open NTP is trivially done in a few hours. Abusing these > servers for reflection attack is as trivial, hence the problem. How can we > get the responsible parties to fix their NTP servers? > > Answer: DDoS them. With their own service. > /me gets some popcorn and waits for the show. -- Landon Stewart From saku at ytti.fi Fri Feb 21 22:22:31 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 22 Feb 2014 00:22:31 +0200 Subject: out of band management gear In-Reply-To: <5307C25B.2080605@brezworks.com> References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> <5307C25B.2080605@brezworks.com> Message-ID: <20140221222231.GA1310@pob.ytti.fi> On (2014-02-21 15:17 -0600), Jeremy Bresley wrote: > connections to devices that needed them. Expensive options in a > fully loaded chassis just for a couple lower-end devices that could > easily justify a couple dollars more to get a Gig PHY instead of the > older 100Mb PHY chip. There is no technical reason why subrateSFP and subrateSFP+ couldn't exist, which is 1GE or 10GE towards host and offers 10/100/1000 towards client. Obviously the optic would be significantly more expensive than normal optic, as it needs to do lot more, including buffering. But if 1GE optic costs 10EUR, this subrate optic could easily cost 100EUR. Just needs some optic vendor to figure out if there is sufficient market for it. Randy suggested it is untypical these days to find kit which does not understand multirate, my experience is the opposite, it's getting rarer to find multirate support. Even in cases when they do it, it's often supposedly mode in SGMII where it can be instructed to send same bit 10 times, allowing cheap 1/10th rate. -- ++ytti From cb.list6 at gmail.com Fri Feb 21 22:37:04 2014 From: cb.list6 at gmail.com (Cb B) Date: Fri, 21 Feb 2014 14:37:04 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: On Feb 22, 2014 5:30 AM, "Damian Menscher" wrote: > > On Fri, Feb 21, 2014 at 1:22 PM, Cb B wrote: >> >> On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher wrote: >> > On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch wrote: >> > You may also want to look at filtering UDP/80 outright as well, as that is >> >> commonly used as an "I'm going to attack port 80" by attackers that don't >> >> quite understand the difference between UDP and TCP. >> > >> > Please don't filter UDP/80. It's used by QUIC ( >> > http://en.wikipedia.org/wiki/QUIC). >> >> The folks at QUIC have been advised to not use UDP for a new protocol, >> and they would be very well advised to not use UDP:80 since that is a >> well known target port used in the DDoS reflection attacks. > > > Please suggest which protocol has less blocking on the internet today (keeping in mind the full end-to-end stack of CPE, various ISPs, country-level proxies, backbone providers, etc). > > Damian Tcp. But the actual answer is , if you want a new transport protocol, create a new transport protocol with a new protocol number. Overloading the clearly polluted UDP pool will have problems. Happy eyeballs negotiation may be required for L4. QUIC can do what it wants. Like anyone else, they pay their money and take their chances. But, the data point that UDP is polluted is clearly documented with several folks on this list suggesting tactical fixes that involve limiting UDP, especially udp:80 From nickrpope at gmail.com Fri Feb 21 19:15:51 2014 From: nickrpope at gmail.com (Nick Pope) Date: Fri, 21 Feb 2014 13:15:51 -0600 Subject: out of band management gear In-Reply-To: <53077462.9050101@winterei.se> References: <53077462.9050101@winterei.se> Message-ID: Thinklogical Sentinel is great. CLI access via ssh, web access, modem for dial in and two ethernet ports for redundant network access, supports up to 32 devices and is dc/ac http://www.thinklogical.com/sentinel From sunyucong at gmail.com Fri Feb 21 20:14:10 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Fri, 21 Feb 2014 12:14:10 -0800 Subject: LAX china unicom submarine cable cut? Message-ID: Well, ain't that great day to finish the week. Some one today me a submarine cable is cut. Most of the networks in LAX that has peering with CU looks congested to hell now. Anyone else here seeing the same thing? From mehmet at akcin.net Fri Feb 21 23:42:36 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 22 Feb 2014 07:42:36 +0800 Subject: LAX china unicom submarine cable cut? In-Reply-To: References: Message-ID: <5244138E-0A51-4038-9B77-3DDCF35BA3D5@akcin.net> What do you see? Packet loss? Latency? Mehmet > On Feb 22, 2014, at 4:14, Yucong Sun wrote: > > Well, ain't that great day to finish the week. Some one today me a > submarine cable is cut. > > Most of the networks in LAX that has peering with CU looks congested to > hell now. Anyone else here seeing the same thing? From sethm at rollernet.us Fri Feb 21 23:45:00 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 21 Feb 2014 15:45:00 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: <5307E4FC.1040407@rollernet.us> Isn't UDP 80 still technically registered to HTTP? ~Seth From esuarez at fcaglp.fcaglp.unlp.edu.ar Sat Feb 22 00:58:57 2014 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Fri, 21 Feb 2014 21:58:57 -0300 Subject: Gmail throttling? Message-ID: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> Hi, some of our users have forwarded the email to Gmail and Gmail now are complaining that this is bulk mail and delaying it. We have SPF, DKIM, DMARC, even SRS to try these things do not happen :( Anyone know if there is any new policy in Gmail about that? Above all, the message refers to a non-existent URI! >>> RSET 250 2.1.5 Flushed v69si8136768yhd.33 - gsmtp ... Using cached ESMTP connection to gmail-smtp-in.l.google.com. via esmtp... >>> MAIL From: SIZE=150374 BODY=8BITMIME 250 2.1.0 OK v69si8136768yhd.33 - gsmtp >>> RCPT To: >>> DATA 250 2.1.5 OK v69si8136768yhd.33 - gsmtp 354 Go ahead v69si8136768yhd.33 - gsmtp >>> . 421-4.7.0 [163.10.4.2 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit http://www.google.com/mail/help/bulk_mail. 421 4.7.0 html to review our Bulk Email Senders Guidelines. v69si8136768yhd.33 - gsmtp >>> QUIT Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From brandon at burn.net Sat Feb 22 01:01:06 2014 From: brandon at burn.net (Brandon Applegate) Date: Fri, 21 Feb 2014 20:01:06 -0500 (EST) Subject: NetSol AAAA glue Message-ID: If anyone with ability to fix this is reading this - contact me offlist and I'll owe you... I'm trying to change an AAAA host (name server) address. I've been emailing ipv6req at networksolutions.com back and forth for several days. After fighting through 'authentication' (which btw I *didn't* do several years ago to get the AAAA added) they say they have 'completed' it. a.gtld for example still has the old AAAA. I've just got a gut feeling that they don't understand what I'm asking. I'm actually getting a bit scared they are going to break my domain. Aside from someone at netsol seeing this - does anyone have any advice other than get off netsol (which I'm considering). Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 "SH1-0151. This is the serial number, of our orbital gun." From marine64 at gmail.com Sat Feb 22 01:03:46 2014 From: marine64 at gmail.com (Brian Henson) Date: Fri, 21 Feb 2014 20:03:46 -0500 Subject: Gmail throttling? In-Reply-To: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> References: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> Message-ID: The correct URL should be https://support.google.com/mail/answer/81126 On Fri, Feb 21, 2014 at 7:58 PM, Eduardo A. Su?rez < esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote: > Hi, > > some of our users have forwarded the email to Gmail and Gmail now are > complaining that this is bulk mail and delaying it. > > We have SPF, DKIM, DMARC, even SRS to try these things do not happen :( > > Anyone know if there is any new policy in Gmail about that? > > Above all, the message refers to a non-existent URI! > > RSET >>>> >>> 250 2.1.5 Flushed v69si8136768yhd.33 - gsmtp > ... Using cached ESMTP connection to > gmail-smtp-in.l.google.com. via esmtp... > >> MAIL From: SIZE=150374 BODY=8BITMIME >>>> >>> 250 2.1.0 OK v69si8136768yhd.33 - gsmtp > >> RCPT To: >>>> DATA >>>> >>> 250 2.1.5 OK v69si8136768yhd.33 - gsmtp > 354 Go ahead v69si8136768yhd.33 - gsmtp > >> . >>>> >>> 421-4.7.0 [163.10.4.2 15] Our system has detected an unusual rate of > 421-4.7.0 unsolicited mail originating from your IP address. To protect our > 421-4.7.0 users from spam, mail sent from your IP address has been > temporarily > 421-4.7.0 rate limited. Please visit http://www.google.com/mail/ > help/bulk_mail. > 421 4.7.0 html to review our Bulk Email Senders Guidelines. > v69si8136768yhd.33 - gsmtp > >> QUIT >>>> >>> > > Eduardo.- > > > -- > Eduardo A. Suarez > Facultad de Ciencias Astron?micas y Geof?sicas - UNLP > FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > From cra at WPI.EDU Sat Feb 22 01:10:26 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 21 Feb 2014 20:10:26 -0500 Subject: NetSol AAAA glue In-Reply-To: References: Message-ID: <20140222011026.GF27322@angus.ind.WPI.EDU> It is quicker and easier to transfer your domain to another registrar, even though you will have to call them up and speak to a person to do it. On Fri, Feb 21, 2014 at 08:01:06PM -0500, Brandon Applegate wrote: > If anyone with ability to fix this is reading this - contact me > offlist and I'll owe you... > > I'm trying to change an AAAA host (name server) address. > > I've been emailing ipv6req at networksolutions.com back and forth for > several days. After fighting through 'authentication' (which btw I > *didn't* do several years ago to get the AAAA added) they say they > have 'completed' it. a.gtld for example still has the old AAAA. > I've just got a gut feeling that they don't understand what I'm > asking. I'm actually getting a bit scared they are going to break > my domain. > > Aside from someone at netsol seeing this - does anyone have any > advice other than get off netsol (which I'm considering). From gdendy at equinix.com Sat Feb 22 05:20:54 2014 From: gdendy at equinix.com (Greg Dendy) Date: Fri, 21 Feb 2014 21:20:54 -0800 Subject: NANOG 61 - Bellevue - Call For Presentations is open! Message-ID: <5A388661-CDD4-4146-9F99-9EFD1ACAE3AE@equinix.com> NANOG Community- I hope everyone enjoyed NANOG 60, NANOG?s largest attended winter meeting. Fresh off a great meeting, and post our NANOG Icelanta Reception, we are ready start the process for NANOG 61 in Bellevue. NANOG 61 will be NANOG?s 20th year serving the network operator community and helping to make the Internet better. If you have a topic you'd like to speak about, the program committee would love to consider it. Please read http://www.nanog.org/meetings/nanog61/callforpresentations for more information. We will continue with the Monday-Wednesday format, with Tracks on Monday and Wednesday afternoons and Tutorials to be scheduled on Tuesday morning. The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch. The exact schedule layout can be found at http://www.nanog.org/meetings/nanog60/preagenda, please take this into account as you plan travel. If you wish to submit a presentation, please keep these important dates in mind: * Presentation Abstracts and Draft Slides Due: April 7, 2014 * Slides Due: May 5, 2014 * Topic List Posted: April 21, 2014 * Agenda Published: May 12, 2014 Please submit your materials to http://pc.nanog.org. Looking forward to seeing everyone in Bellevue! Thanks, Greg Dendy Chair, NANOG Program Committee From ops.lists at gmail.com Sat Feb 22 07:42:16 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 21 Feb 2014 23:42:16 -0800 Subject: Gmail throttling? In-Reply-To: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> References: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> Message-ID: Auto forwarded mail is like that. Any inbound spam your users receive also gets forwarded. So... On 22-Feb-2014 1:00 AM, "Eduardo A. Su?rez" < esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote: > Hi, > > some of our users have forwarded the email to Gmail and Gmail now are > complaining that this is bulk mail and delaying it. > > We have SPF, DKIM, DMARC, even SRS to try these things do not happen :( > > Anyone know if there is any new policy in Gmail about that? > > Above all, the message refers to a non-existent URI! > > RSET >>>> >>> 250 2.1.5 Flushed v69si8136768yhd.33 - gsmtp > ... Using cached ESMTP connection to > gmail-smtp-in.l.google.com. via esmtp... > >> MAIL From: SIZE=150374 BODY=8BITMIME >>>> >>> 250 2.1.0 OK v69si8136768yhd.33 - gsmtp > >> RCPT To: >>>> DATA >>>> >>> 250 2.1.5 OK v69si8136768yhd.33 - gsmtp > 354 Go ahead v69si8136768yhd.33 - gsmtp > >> . >>>> >>> 421-4.7.0 [163.10.4.2 15] Our system has detected an unusual rate of > 421-4.7.0 unsolicited mail originating from your IP address. To protect our > 421-4.7.0 users from spam, mail sent from your IP address has been > temporarily > 421-4.7.0 rate limited. Please visit http://www.google.com/mail/ > help/bulk_mail. > 421 4.7.0 html to review our Bulk Email Senders Guidelines. > v69si8136768yhd.33 - gsmtp > >> QUIT >>>> >>> > > Eduardo.- > > > -- > Eduardo A. Suarez > Facultad de Ciencias Astron?micas y Geof?sicas - UNLP > FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > From saku at ytti.fi Sat Feb 22 07:47:19 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 22 Feb 2014 09:47:19 +0200 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> Message-ID: <20140222074719.GA11705@pob.ytti.fi> On (2014-02-21 14:37 -0800), Cb B wrote: > QUIC can do what it wants. Like anyone else, they pay their money and take > their chances. But, the data point that UDP is polluted is clearly > documented with several folks on this list suggesting tactical fixes that > involve limiting UDP, especially udp:80 Seth has good point, UDP:80 is HTTP. If we want new L4 protocol which works today, we must first ride on top of UDP, since that will work on lot more people day 1, this will avoid chicken-egg problem (kit won't be fixed,as no one uses new L4, no one uses new L4 as lot of kit drops it) I'm surprised MinimaLT and QUIC have have not put transport area people in high gear towards standardization of new PKI based L4 protocol, I think its elegant solution to many practical reoccurring problem, solution which has become practical only rather recently. -- ++ytti From pmsac.nanog at gmail.com Sat Feb 22 08:32:16 2014 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Sat, 22 Feb 2014 08:32:16 +0000 Subject: Gmail throttling? In-Reply-To: References: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> Message-ID: On 22 February 2014 01:03, Brian Henson wrote: > The correct URL should be https://support.google.com/mail/answer/81126 The URL is actually correct, it just happens that the "html" part in "bulk_mail.html" only shows up on the next line - if you use it, it eventually redirects to the above. > > > On Fri, Feb 21, 2014 at 7:58 PM, Eduardo A. Su?rez < > esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote: > >> Hi, >> >> some of our users have forwarded the email to Gmail and Gmail now are >> complaining that this is bulk mail and delaying it. >> >> We have SPF, DKIM, DMARC, even SRS to try these things do not happen :( >> >> Anyone know if there is any new policy in Gmail about that? >> >> Above all, the message refers to a non-existent URI! >> >> RSET >>>>> >>>> 250 2.1.5 Flushed v69si8136768yhd.33 - gsmtp >> ... Using cached ESMTP connection to >> gmail-smtp-in.l.google.com. via esmtp... >> >>> MAIL From: SIZE=150374 BODY=8BITMIME >>>>> >>>> 250 2.1.0 OK v69si8136768yhd.33 - gsmtp >> >>> RCPT To: >>>>> DATA >>>>> >>>> 250 2.1.5 OK v69si8136768yhd.33 - gsmtp >> 354 Go ahead v69si8136768yhd.33 - gsmtp >> >>> . >>>>> >>>> 421-4.7.0 [163.10.4.2 15] Our system has detected an unusual rate of >> 421-4.7.0 unsolicited mail originating from your IP address. To protect our >> 421-4.7.0 users from spam, mail sent from your IP address has been >> temporarily >> 421-4.7.0 rate limited. Please visit http://www.google.com/mail/ >> help/bulk_mail. >> 421 4.7.0 html to review our Bulk Email Senders Guidelines. >> v69si8136768yhd.33 - gsmtp >> >>> QUIT >>>>> >>>> >> >> Eduardo.- >> >> >> -- >> Eduardo A. Suarez >> Facultad de Ciencias Astron?micas y Geof?sicas - UNLP >> FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> From cabo at tzi.org Sat Feb 22 08:38:45 2014 From: cabo at tzi.org (Carsten Bormann) Date: Sat, 22 Feb 2014 09:38:45 +0100 Subject: Filter NTP traffic by packet size? In-Reply-To: <20140222074719.GA11705@pob.ytti.fi> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> Message-ID: <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> On 22 Feb 2014, at 08:47, Saku Ytti wrote: > I'm surprised MinimaLT and QUIC have have not put transport area people in > high gear towards standardization of new PKI based L4 protocol, I think its > elegant solution to many practical reoccurring problem, solution which has > become practical only rather recently. Oh, the transport area people *are* in their high gear. Their frantic movements may just seem static to you as they operate on more drawn-out time scales. (The last transport protocol I worked on became standards-track 16 years after I started working on it.) At this IETF, there will be a ?Transport Services? BOF to help find out what exactly the services are that a new transport protocol should provide to the applications. Research platforms such as QUIC, tcpcrypt, MINION etc. are very much in the focus of attention. This time, it would be nice if the operations people got to have a say early on in what gets standardized. (Just be careful not to try to ?fight yesterday?s war?.) Gr??e, Carsten From cb.list6 at gmail.com Sat Feb 22 09:07:18 2014 From: cb.list6 at gmail.com (Cb B) Date: Sat, 22 Feb 2014 01:07:18 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> Message-ID: On Sat, Feb 22, 2014 at 12:38 AM, Carsten Bormann wrote: > On 22 Feb 2014, at 08:47, Saku Ytti wrote: > >> I'm surprised MinimaLT and QUIC have have not put transport area people in >> high gear towards standardization of new PKI based L4 protocol, I think its >> elegant solution to many practical reoccurring problem, solution which has >> become practical only rather recently. > > Oh, the transport area people *are* in their high gear. > Their frantic movements may just seem static to you as they operate on more drawn-out time scales. > (The last transport protocol I worked on became standards-track 16 years after I started working on it.) > > At this IETF, there will be a "Transport Services" BOF to help find out what exactly the services are that a new transport protocol should provide to the applications. Research platforms such as QUIC, tcpcrypt, MINION etc. are very much in the focus of attention. > > This time, it would be nice if the operations people got to have a say early on in what gets standardized. > (Just be careful not to try to "fight yesterday's war".) > > Gr??e, Carsten > > yesterday's war = don't bring up that operators are having a real problem with UDP, and that operators have and will continue to block it? Because, i think that is what this thread is about. i did bring yesterday's war to the IETF RTCWweb group and got the expected answer My concern: https://www.ietf.org/mail-archive/web/rtcweb/current/msg11425.html Summary IETF response: The problem i described is already solved by bcp38, nothing to see here, carry on with UDP https://www.ietf.org/mail-archive/web/rtcweb/current/msg11477.html CB From cabo at tzi.org Sat Feb 22 09:48:09 2014 From: cabo at tzi.org (Carsten Bormann) Date: Sat, 22 Feb 2014 10:48:09 +0100 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> Message-ID: <6E5CF4D9-21DF-42A2-9FA3-C76D023E450B@tzi.org> >> (Just be careful not to try to "fight yesterday's war?.) > yesterday's war = don't bring up that operators are having a real > problem with UDP, No, you don?t. You are having a problem with applications that enable strongly amplified reflection. (Yes, after the days of smurf passed, these are all on UDP, because it is hard to make that mistake with TCP, and nothing else is deployable. Still, your problem is not ?with UDP?, but with those applications.) The obvious solution for a new protocol is to make sure that it doesn?t have that problem, whether it is layered on UDP or something else. (In yesterday?s network, it *only* can be layered on UDP, because nothing else goes through NATs.) Also, note that the NTP issue we are seeing right now is not a protocol problem at all, it is all about shoddy implementation. The next problem is that the hammers you have to fix this at the network level really aren?t that good for fixing the rust on those implementations. The QUIC people tell us they are able to talk UDP to about 93 % of the people they can talk TCP to. So a part of the network will be stuck with running their applications on today?s TCP. But that doesn?t mean that we can?t layer useful new stuff on UDP, it just will be less universally available. (With those new applications coming online, blanket filtering of UDP will be exposed even more as the low-ball networking that it is, so I expect the workability of UDP to go up over time, not down.) Gr??e, Carsten From saku at ytti.fi Sat Feb 22 10:05:46 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 22 Feb 2014 12:05:46 +0200 Subject: Filter NTP traffic by packet size? In-Reply-To: <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> Message-ID: <20140222100546.GA29302@pob.ytti.fi> On (2014-02-22 09:38 +0100), Carsten Bormann wrote: > Oh, the transport area people *are* in their high gear. > Their frantic movements may just seem static to you as they operate on more drawn-out time scales. > (The last transport protocol I worked on became standards-track 16 years after I started working on it.) This seems to be common problem when things mature. Established companies take years to produce new product, and then they are so committed on the new product that no one dares to call it failure and they keep on supporting it. People tend to think that future can be predicted with enough work, I don't think that is true. I suspect amount work put in product has rapidly diminishing returns. It seems much more effective to release often, release early and fail early. I think Joel Jaeggli once said 'maturing Internet infrastructure resists innovation', I really like that quote. Is this a problem that should be remedied? Should we move faster? Could transport area endorse and release new pre-standard document for L4 every 4months? 6months? 12months? Guaranteeing no particular compatibility between this and next pre-standard release? If there would be newL4 directory in linux kernel and someone saw the trouble to write it, it seems like barrier of entry for someone else to later update it to reflect latest pre-standard changes is pretty small. The initial work has high barrier of entry. -- ++ytti From rsk at gsp.org Sat Feb 22 12:41:29 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 22 Feb 2014 07:41:29 -0500 Subject: The somewhat illegal fix for NTP attacks In-Reply-To: References: Message-ID: <20140222124128.GA24205@gsp.org> It's never appropriate to respond to abuse with abuse. Not only is it questionable/unprofessional behavior, but -- as we've seen -- there is a high risk that it'll exacerbate the problem, often by targeting innocent third parties. I understand the frustration but this is not the way. ---rsk From jared at puck.nether.net Sat Feb 22 12:43:21 2014 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 22 Feb 2014 07:43:21 -0500 Subject: The somewhat illegal fix for NTP attacks In-Reply-To: References: Message-ID: <96300643-6D15-4945-9833-93F6A31BE4B6@puck.nether.net> On Feb 21, 2014, at 5:08 PM, Baldur Norddahl wrote: > Hi > > The following would probably be illegal so do not actually do this. But > what if... there are just 4 billion IPv4 addresses. Scanning that > address-space for open NTP is trivially done in a few hours. Abusing these > servers for reflection attack is as trivial, hence the problem. How can we > get the responsible parties to fix their NTP servers? > > Answer: DDoS them. With their own service. One of the attacks that was mitigated the fastest was the SQL Slammer worm due to the broad impact it had across the internet. The OpenNTP and OpenResolver projects provide inventories of these servers for operators to take action and to take to their customer cone. > Or it could be a DDoS defense. As a victim of an ongoing NTP reflection > attack, you know exactly the IP-addresses of the vulnerable NTP servers > used to attack you. Make them stop by sending back forged NTP packets, so > they use up their available bandwidth to DDoS each other instead of you. > This could even be automated. If you let them attack their next-hop as > discovered by traceroute, it might not even be illegal or harmful. They > will only bring down their own link, do no more harm to the internet at > large and they can fix it by stopping the NTP service. If they are part of > an ongoing DDoS attack it is just self defence to shut them down in the > least harmful way possible. Do you have a letter from the local law enforcement or legal counsel on this topic? If so, can you please share it with the class or submit a presentation to an upcoming conference on this? - Jared From nathana at fsr.com Sat Feb 22 12:55:37 2014 From: nathana at fsr.com (Nathan Anderson) Date: Sat, 22 Feb 2014 04:55:37 -0800 Subject: Gmail throttling? In-Reply-To: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> References: <20140221215857.t6rjafajs4ccww84@fcaglp.fcaglp.unlp.edu.ar> Message-ID: On Friday, February 21, 2014 4:59 PM, Eduardo A. Su?rez wrote: > some of our users have forwarded the email to Gmail and Gmail now are > complaining that this is bulk mail and delaying it. > > We have SPF, DKIM, DMARC, even SRS to try these things do not happen :( Have you double-checked your setup to make sure it is performing SRS correctly? In my experience, Google is secretly blacklisting certain IPs for unknown, unpublished reasons, and implementing SRS seems to be a surefire workaround. If you aren't on the secret blacklist, mail will still pass even if it fails SPF, but once you are on the blacklist, mail that fails SPF (either softfail or fail) will not be delivered. If a user of yours is forwarding mail from your server to Gmail, the SPF check is not going to be against *your* SPF record, but against the original sender's SPF record, and so the check will fail (since the message looks like it is coming from you, and your MX won't be listed in the original sender's SPF record...thus, it will look like you are spoofing mail for the original sender). Adding a valid SPF record to your domain and then implementing SRS on your mail server should ensure that all SPF checks pass, even for mail that your users are forwarding to Gmail. I wrote a post detailing my experience and findings: http://www.brokenbitstream.com/gmail-spf-policy -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From maillist at webjogger.net Sat Feb 22 13:53:41 2014 From: maillist at webjogger.net (Adam Greene) Date: Sat, 22 Feb 2014 08:53:41 -0500 Subject: out of band management gear In-Reply-To: References: <53077462.9050101@winterei.se> Message-ID: <007301cf2fd5$7e6c73d0$7b455b70$@webjogger.net> We used old fashioned Cisco 2500's with octal cables. Old school for small deployments. We have toyed with the idea of trying to obtain OOB access via 3G/4G instead of using a dialup modem. Has anyone tried that and if so, what hardware would you recommend? -----Original Message----- From: Nick Pope [mailto:nickrpope at gmail.com] Sent: Friday, February 21, 2014 2:16 PM To: nanog at nanog.org Subject: Re: out of band management gear Thinklogical Sentinel is great. CLI access via ssh, web access, modem for dial in and two ethernet ports for redundant network access, supports up to 32 devices and is dc/ac http://www.thinklogical.com/sentinel From nick at foobar.org Sat Feb 22 15:06:32 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 22 Feb 2014 15:06:32 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> Message-ID: <5308BCF8.9060801@foobar.org> On 22/02/2014 09:07, Cb B wrote: > Summary IETF response: The problem i described is already solved by > bcp38, nothing to see here, carry on with UDP udp is here to stay. Denying this is no more useful than trying to push the tide back with a teaspoon. It's worth bearing in mind that any open tcp service will send out several acks before giving up. In other words, any standard open tcp socket will provide a level of amplification worth using even if UDP were to be switched off tomorrow. Sure, not as good as the 230x amplification that ntp monlist will give, but it's still a problem. In the long term, it would be more useful to spent time and effort building automated tools to track down the sources of the spoofed packets than trying to deprecate UDP. Nick From fergdawgster at mykolab.com Sat Feb 22 16:04:10 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sat, 22 Feb 2014 08:04:10 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <5308BCF8.9060801@foobar.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> Message-ID: <5308CA7A.4020905@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/22/2014 7:06 AM, Nick Hilliard wrote: > On 22/02/2014 09:07, Cb B wrote: >> Summary IETF response: The problem i described is already solved >> by bcp38, nothing to see here, carry on with UDP > > udp is here to stay. Denying this is no more useful than trying to > push the tide back with a teaspoon. > Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage my competitors to block udp." :-p - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M =FTxg -----END PGP SIGNATURE----- From Petter.Bruland at allegiantair.com Sat Feb 22 16:32:25 2014 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Sat, 22 Feb 2014 16:32:25 +0000 Subject: out of band management gear In-Reply-To: <007301cf2fd5$7e6c73d0$7b455b70$@webjogger.net> References: <53077462.9050101@winterei.se> , <007301cf2fd5$7e6c73d0$7b455b70$@webjogger.net> Message-ID: We're using VerizonWireless CradlePoints, Fortigate 80C firewalls, and Digi CM32's for our OOB solution. There were a few times when VerizonWireless went down, but at those times we did not have the emergency need to be on the OOB network. It's a simple setup and not too costly. We got the CM32s on eBay for $50/ea, not too bad. We also have one site with a 2500 and octal cables, which is rock solid. Lately I've been getting a lot of SPAM for 3rd party OOB management solutions. So there seem to be plenty of alternatives to a good OOB setup. Petter Bruland | Network Engineer Allegiant Travel Company 8360 S. Durango Drive, Las Vegas, NV 89113 Phone: (702) 874-3332 | Cell: (702) 286-6549 petter.bruland at allegiantair.com http://www.allegiantair.com ________________________________________ From: Adam Greene [maillist at webjogger.net] Sent: Saturday, February 22, 2014 5:53 AM To: nanog at nanog.org Subject: RE: out of band management gear We used old fashioned Cisco 2500's with octal cables. Old school for small deployments. We have toyed with the idea of trying to obtain OOB access via 3G/4G instead of using a dialup modem. Has anyone tried that and if so, what hardware would you recommend? -----Original Message----- From: Nick Pope [mailto:nickrpope at gmail.com] Sent: Friday, February 21, 2014 2:16 PM To: nanog at nanog.org Subject: Re: out of band management gear Thinklogical Sentinel is great. CLI access via ssh, web access, modem for dial in and two ethernet ports for redundant network access, supports up to 32 devices and is dc/ac http://www.thinklogical.com/sentinel From mysidia at gmail.com Sat Feb 22 21:09:06 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 22 Feb 2014 15:09:06 -0600 Subject: The somewhat illegal fix for NTP attacks In-Reply-To: <20140222124128.GA24205@gsp.org> References: <20140222124128.GA24205@gsp.org> Message-ID: On Sat, Feb 22, 2014 at 6:41 AM, Rich Kulawiec wrote: Perhaps you would rather publish a blacklist of "/24s containing NTP servers open to MONLIST" over UDP port 123 similar to the bogon feeds. And encourage all networks to blackhole the list. That way potential NTP reflection abuse traffic gets stuffed as close to the source as possible. > It's never appropriate to respond to abuse with abuse. Not only is > it questionable/unprofessional behavior, but -- as we've seen -- there > is a high risk that it'll exacerbate the problem, often by targeting > innocent third parties. > > I understand the frustration but this is not the way. > > ---rsk -- -JH From claffin at peer1.com Sun Feb 23 00:43:34 2014 From: claffin at peer1.com (Chris Laffin) Date: Sun, 23 Feb 2014 00:43:34 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <5308CA7A.4020905@mykolab.com> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>,<5308CA7A.4020905@mykolab.com> Message-ID: <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. > On Feb 22, 2014, at 8:05, "Paul Ferguson" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >> >>> On 22/02/2014 09:07, Cb B wrote: >>> Summary IETF response: The problem i described is already solved >>> by bcp38, nothing to see here, carry on with UDP >> >> udp is here to stay. Denying this is no more useful than trying to >> push the tide back with a teaspoon. > > Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage > my competitors to block udp." :-p > > - - ferg > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS > OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M > =FTxg > -----END PGP SIGNATURE----- > From randy at psg.com Sun Feb 23 00:51:16 2014 From: randy at psg.com (Randy Bush) Date: Sun, 23 Feb 2014 08:51:16 +0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <6E5CF4D9-21DF-42A2-9FA3-C76D023E450B@tzi.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <6E5CF4D9-21DF-42A2-9FA3-C76D023E450B@tzi.org> Message-ID: > The obvious solution for a new protocol is to make sure that it > doesn?t have that problem, whether it is layered on UDP or something > else. i'll settle for configured by default not to welcome amplification queries with open arms. let's not throw the baby out with the bathwater (excuse the yank idiom) randy From peter.phaal at gmail.com Sun Feb 23 03:22:57 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 22 Feb 2014 19:22:57 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> Message-ID: Brocade demonstrated how peering exchanges can selectively filter large NTP reflection flows using the sFlow monitoring and hybrid port OpenFlow capabilities of their MLXe switches at last week's Network Field Day event. http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin wrote: > Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. > >> On Feb 22, 2014, at 8:05, "Paul Ferguson" wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >>> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >>> >>>> On 22/02/2014 09:07, Cb B wrote: >>>> Summary IETF response: The problem i described is already solved >>>> by bcp38, nothing to see here, carry on with UDP >>> >>> udp is here to stay. Denying this is no more useful than trying to >>> push the tide back with a teaspoon. >> >> Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage >> my competitors to block udp." :-p >> >> - - ferg >> >> >> - -- >> Paul Ferguson >> VP Threat Intelligence, IID >> PGP Public Key ID: 0x54DC85B2 >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS >> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M >> =FTxg >> -----END PGP SIGNATURE----- >> > From bmanning at vacation.karoshi.com Sun Feb 23 10:08:39 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 23 Feb 2014 02:08:39 -0800 Subject: [5350-5470 MHz] Message-ID: <20140223100839.GD10536@vacation.karoshi.com> if you have comments or feedback.... ----- Forwarded message from "Julie N" ----- Date: Wed, 19 Feb 2014 21:34:51 +0000 Subject: 5350-5470 MHz Dear Members, As you know, we have been actively engaged in the International Telecommunication Union's (ITU) Joint Task Group (JTG) studies to consider additional spectrum allocations to the mobile service for terrestrial mobile broadband applications and identification of frequency bands for International Mobile Telecommunications (IMT) at the 2015 World Radiocommunication Conference (WRC-15). The United States is currently considering 5350-5470 MHz for Unlicensed National Information Infrastructure (U-NII) devices radio local area networks (RLANs). We are working with NTIA, FCC, federal agencies and industry to ensure that the necessary analyses are completed and interference avoidance or mitigation techniques are developed and demonstrated in time to resolve concerns and to develop international support for a U.S. position. I am attaching a letter from Ambassador Sepulveda containing important information about this band and our commitment to working with you to mobilize spectrum for wireless broadband. I look forward to working with you on this and many other important WRC-15 issues. Best regards, Julie This email is UNCLASSIFIED. ----- End forwarded message ----- From claffin at peer1.com Sun Feb 23 14:58:36 2014 From: claffin at peer1.com (Chris Laffin) Date: Sun, 23 Feb 2014 14:58:36 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, Message-ID: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? > On Feb 22, 2014, at 19:23, "Peter Phaal" wrote: > > Brocade demonstrated how peering exchanges can selectively filter > large NTP reflection flows using the sFlow monitoring and hybrid port > OpenFlow capabilities of their MLXe switches at last week's Network > Field Day event. > > http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html > >> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin wrote: >> Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. >> >>> On Feb 22, 2014, at 8:05, "Paul Ferguson" wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >>>>> >>>>> On 22/02/2014 09:07, Cb B wrote: >>>>> Summary IETF response: The problem i described is already solved >>>>> by bcp38, nothing to see here, carry on with UDP >>>> >>>> udp is here to stay. Denying this is no more useful than trying to >>>> push the tide back with a teaspoon. >>> >>> Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage >>> my competitors to block udp." :-p >>> >>> - - ferg >>> >>> >>> - -- >>> Paul Ferguson >>> VP Threat Intelligence, IID >>> PGP Public Key ID: 0x54DC85B2 >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS >>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M >>> =FTxg >>> -----END PGP SIGNATURE----- >> From swmike at swm.pp.se Sun Feb 23 15:14:52 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 23 Feb 2014 16:14:52 +0100 (CET) Subject: Filter NTP traffic by packet size? In-Reply-To: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Message-ID: On Sun, 23 Feb 2014, Chris Laffin wrote: > Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? If only there was more focus on the BCP38 offenders who are the real root cause of this problem, I would be more happy. I would be more impressed if the IXes would start to use their sFlow capabilities to find out what IX ports the NTP queries are coming to backtrace the traffic to the BCP38 offendors than try to block the NTP packets resulting from these src address forged queries. -- Mikael Abrahamsson email: swmike at swm.pp.se From peter.phaal at gmail.com Sun Feb 23 17:03:59 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Sun, 23 Feb 2014 09:03:59 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Message-ID: What is the business model for the IX? Unauthorized filtering of incoming traffic risks collateral damage and outing exchange members seems problematic. The business model seems clearer when offering filtering as a service to downstream networks, the effects are narrowly scoped, and members have control over the traffic they accept from the exchange, e.g. I don't want to accept NTP traffic to any destination that exceeds 1Gbit/s, or is sourced from an NTP server on my blacklist. Giving policy control to the downstream allows them to protect their networks and make business decisions about how they want to prioritize services and customers when resources are constrained. Would exchange members pay for this type of control? DDoS mitigation appears to be less of a technical problem than an issue of misaligned costs and benefits. How do you create incentives for upstream providers to invest in solutions when the benefits accrue downstream? On Sun, Feb 23, 2014 at 7:14 AM, Mikael Abrahamsson wrote: > On Sun, 23 Feb 2014, Chris Laffin wrote: > >> Ive talked to some major peering exchanges and they refuse to take any >> action. Possibly if the requests come from many peering participants it will >> be taken more seriously? > > > If only there was more focus on the BCP38 offenders who are the real root > cause of this problem, I would be more happy. > > I would be more impressed if the IXes would start to use their sFlow > capabilities to find out what IX ports the NTP queries are coming to > backtrace the traffic to the BCP38 offendors than try to block the NTP > packets resulting from these src address forged queries. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From bedard.phil at gmail.com Sun Feb 23 17:26:09 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 23 Feb 2014 09:26:09 -0800 Subject: Filter NTP traffic by packet size? Message-ID: <4437683555356305743@unknownmsgid> On Sun, 23 Feb 2014, Chris Laffin wrote: > Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? If only there was more focus on the BCP38 offenders who are the real root cause of this problem, I would be more happy. I would be more impressed if the IXes would start to use their sFlow capabilities to find out what IX ports the NTP queries are coming to backtrace the traffic to the BCP38 offendors than try to block the NTP packets resulting from these src address forged queries. -- Mikael Abrahamsson email: swmike at swm.pp.se From sthaug at nethelp.no Sun Feb 23 17:29:45 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 23 Feb 2014 18:29:45 +0100 (CET) Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Message-ID: <20140223.182945.74711117.sthaug@nethelp.no> > The business model seems clearer when offering filtering as a service > to downstream networks, the effects are narrowly scoped, and members > have control over the traffic they accept from the exchange, e.g. I > don't want to accept NTP traffic to any destination that exceeds > 1Gbit/s, or is sourced from an NTP server on my blacklist. Giving > policy control to the downstream allows them to protect their networks > and make business decisions about how they want to prioritize services > and customers when resources are constrained. > > Would exchange members pay for this type of control? Speaking only for myself: No. The L2 IXes I connect to should use their resources for packet switching, not filtering. Way too many things that could go wrong if we go down the filtering path... Steinar Haug, AS 2116 From lukasz at bromirski.net Sun Feb 23 17:50:49 2014 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Sun, 23 Feb 2014 18:50:49 +0100 Subject: Filter NTP traffic by packet size? In-Reply-To: <20140223.182945.74711117.sthaug@nethelp.no> References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> Message-ID: On 23 Feb 2014, at 18:29, sthaug at nethelp.no wrote: > Speaking only for myself: No. The L2 IXes I connect to should use their > resources for packet switching, not filtering. Way too many things that > could go wrong if we go down the filtering path? Indeed. Most of the L2 IXes run on very ?cost-optimized? solutions just to switch as fast as they can without going in details of what actually is being switched - at least in Europe. To do some additional checks would require extensive testing, platforms capable of doing this in predictable manner (stability, performance) and obviously - a lot more work than it costs today. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From swmike at swm.pp.se Sun Feb 23 18:24:44 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 23 Feb 2014 19:24:44 +0100 (CET) Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Message-ID: On Sun, 23 Feb 2014, Peter Phaal wrote: > What is the business model for the IX? Unauthorized filtering of > incoming traffic risks collateral damage and outing exchange members > seems problematic. I never proposed for them to filter. I was talking about *finding out* who are the sources of these ddos attacks (ie don't do BCP38 filtering) and publish this data. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sun Feb 23 18:25:52 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 23 Feb 2014 19:25:52 +0100 (CET) Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> Message-ID: On Sun, 23 Feb 2014, Lukasz Bromirski wrote: > To do some additional checks would require extensive testing, platforms > capable of doing this in predictable manner (stability, performance) and > obviously - a lot more work than it costs today. A lot of IXes already do sFlow so all the work I proposed would be on the sFlow collector side which has nothing to do with the packet forwarding performance of the IX. -- Mikael Abrahamsson email: swmike at swm.pp.se From george.herbert at gmail.com Sun Feb 23 18:36:42 2014 From: george.herbert at gmail.com (George William Herbert) Date: Sun, 23 Feb 2014 10:36:42 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> Message-ID: <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> On Feb 23, 2014, at 9:50 AM, Lukasz Bromirski wrote: > To do some additional checks would require extensive testing, platforms > capable of doing this in predictable manner (stability, performance) > and obviously - a lot more work than it costs today. What are the costs and stability impacts of the DDOS that are running now? Everyone is asserting it's someone else's problem. Which in a sense it is. But what goes around will come around. If you are not BCP 38 you are sourcing problems. If you are transiting or IXPing someone who isn't BCP 38 you are enabling problems. Is what we are doing now good enough? Probably not. It would take fewer IXP and transit providers adding analysis capability to backtrack than endpoints. So the enablers are more capable of effecting change. They are less to blame in the first place, but not blameless. To assert blamelessness is a form of Tragedy of the Commons. If it's crossing your link or switch, you ARE in the responsibility chain. The last thing I would like to see is large orgs starting to retreat away from open interconnect because of DDOS coming in from less well managed parts of the net. Perhaps BCP 38 implementation will rise fast enough that these things will not become real, but we have been hearing that for 15 plus years now... At some point, the "38 will work by itself!" line approaches "Look at the Emperors' fine new clothes!". -george william herbert george.herbert at gmail.com Sent from Kangphone From royce at techsolvency.com Sun Feb 23 19:48:09 2014 From: royce at techsolvency.com (Royce Williams) Date: Sun, 23 Feb 2014 10:48:09 -0900 Subject: Filter NTP traffic by packet size? In-Reply-To: <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> Message-ID: Newb question ... other than retrofitting, what stands in the way of making BCP38 a condition of peering? Royce From royce at techsolvency.com Sun Feb 23 20:11:50 2014 From: royce at techsolvency.com (Royce Williams) Date: Sun, 23 Feb 2014 11:11:50 -0900 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> Message-ID: On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams wrote: > Newb question ... other than retrofitting, what stands in the way of > making BCP38 a condition of peering? In other words ... if it's a problem of awareness, could upstreams automate warning their downstreams? What about teaching RADb to periodically test for BCP38 compliance, send soft warnings (with links to relevant pages on www.bcp38.info), and publish stats? Continuing my na?vet? ...what if upstreams required BCP38 compliance before updating BGP filters? This would require a soft rollout -- we'd have to give them a few months' warning to not interfere with revenue streams -- but it sounds like nothing's going to change until it starts hitting the pocketbooks. Royce From joelja at bogus.com Sun Feb 23 20:31:16 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 23 Feb 2014 12:31:16 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> Message-ID: <530A5A94.7000408@bogus.com> On 2/23/14, 12:11 PM, Royce Williams wrote: > On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams wrote: >> Newb question ... other than retrofitting, what stands in the way of >> making BCP38 a condition of peering? Peering is frequently but harldy exclusively on a best effort basis, e.g. you agree to exchange traffic, but also agree to hold each other harmless if something bad happens. that's any easy enough contract for most entities to enter into > In other words ... if it's a problem of awareness, could upstreams > automate warning their downstreams? What about teaching RADb to > periodically test for BCP38 compliance, send soft warnings (with links > to relevant pages on www.bcp38.info), and publish stats? > > Continuing my na?vet? ...what if upstreams required BCP38 compliance > before updating BGP filters? my upstreams adjust their filters when I update radb. > This would require a soft rollout -- > we'd have to give them a few months' warning to not interfere with > revenue streams -- but it sounds like nothing's going to change until > it starts hitting the pocketbooks. > > Royce > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From james.braunegg at micron21.com Sun Feb 23 21:39:08 2014 From: james.braunegg at micron21.com (James Braunegg) Date: Sun, 23 Feb 2014 21:39:08 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <530A5A94.7000408@bogus.com> References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> <530A5A94.7000408@bogus.com> Message-ID: Dear All I released a bit of a blog article last week about filtering NTP request traffic via packet size which might be of interest ! So far I known of an unknown tool makes a default request packet of 50 bytes in size ntpdos.py makes a default request packet of 60 bytes in size ntp_monlist.py makes a default request packet of 234 bytes in size monlist from ntpdc makes a default request packet of 234 bytes in size In contrast a normal NTP request for a time sync is about 90 bytes in size More information and some graphs can be found here http://www.micron21.com/ddos-ntp.php Kindest Regards James Braunegg P:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? W:??www.micron21.com/ddos-protection T:?@micron21 This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: joel jaeggli [mailto:joelja at bogus.com] Sent: Monday, February 24, 2014 7:31 AM To: Royce Williams; nanog at nanog.org Subject: Re: Filter NTP traffic by packet size? On 2/23/14, 12:11 PM, Royce Williams wrote: > On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams wrote: >> Newb question ... other than retrofitting, what stands in the way of >> making BCP38 a condition of peering? Peering is frequently but harldy exclusively on a best effort basis, e.g. you agree to exchange traffic, but also agree to hold each other harmless if something bad happens. that's any easy enough contract for most entities to enter into > In other words ... if it's a problem of awareness, could upstreams > automate warning their downstreams? What about teaching RADb to > periodically test for BCP38 compliance, send soft warnings (with links > to relevant pages on www.bcp38.info), and publish stats? > > Continuing my na?vet? ...what if upstreams required BCP38 compliance > before updating BGP filters? my upstreams adjust their filters when I update radb. > This would require a soft rollout -- > we'd have to give them a few months' warning to not interfere with > revenue streams -- but it sounds like nothing's going to change until > it starts hitting the pocketbooks. > > Royce > > From brandon at rd.bbc.co.uk Mon Feb 24 00:26:21 2014 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 24 Feb 2014 00:26:21 GMT Subject: Filter NTP traffic by packet size? Message-ID: <201402240026.AAA16386@sunf10.rd.bbc.co.uk> > > What is the business model for the IX? Unauthorized filtering of > > incoming traffic risks collateral damage and outing exchange members > > seems problematic. > > I never proposed for them to filter. What is missing is filtering at IXP not by IXP. Most transits have blackhole communities so you can drop the DoS through them but peers usually do not. You end up shutting peering so your transit will drop it for you, not ideal. We could agree per peer to do the same but with route servers and lots of peers a standard for community and acceptance of it would be handy. Obviously there is risk in doing this with (lots of) peers as they tend to be prefix limited, not address filtered. brandon From randy at psg.com Mon Feb 24 00:35:33 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Feb 2014 08:35:33 +0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> Message-ID: > Ive talked to some major peering exchanges and they refuse to take any > action. Possibly if the requests come from many peering participants > it will be taken more seriously? i have talked to fiber providers and they have refused to take action. perhaps if requests came from hundreds of the unclued zombies they would take it seriously. randy From joelja at bogus.com Mon Feb 24 04:16:41 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 23 Feb 2014 20:16:41 -0800 Subject: out of band management gear In-Reply-To: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> Message-ID: <530AC7A9.1020800@bogus.com> On 2/21/14, 12:27 PM, Randy Carpenter wrote: > > OpenGear's newer stuff is Gigabit (SFP even). > > I've not seen any real switch made in the last decade that has a problem with 100Mb/s connections. Ancient cisco, maybe had issues. > there are a substantial number of 10Gb/s switch that cannot do tri-rate on copper sfps. in previous $job oob--ilo-ports doing WOL/ and cdu(s) were the annoying 100Mbs/s only devices. terminal servers (all advocent in this case) made the jump aleady. > thanks, > -Randy > > -- > Randy Carpenter > Vice President - IT Services > First Network Group, Inc. > (800)578-6381, Opt. 1 > http://www.network1.net > http://www.facebook.com/FirstNetworkGroup > > ----- Original Message ----- >> We're really pleased with the Perle IOLAN line. They even have a gigabit >> port without a $10k price tag. Amazing! >> >> It really dumbfounds me why so many vendors are still putting 10/100 >> Ethernet ports on their OOB management (looking at you OpenGear). >> Especially a PITA today since many switchports today don't support links >> speeds less than a gigabit. >> >> -richard >> >> >> On Fri, Feb 21, 2014 at 2:39 PM, Hank Disuko wrote: >> >>> Hi folks, >>> I wonder if anyone has good experiences to share with out-of-band hardware? >>> I'm looking for a good OOB hardware vendor. I need to manage my >>> routers/switches/firewalls in a datacenter located overseas, and I'm >>> looking to setup a good serial console server via an OOB link. >>> I've been looking at Lantronix, OpenGear, Raritan...but they all seem to >>> have the same basic features. I'm having trouble really differentiating >>> them. >>> I'm interested in analog modem, cellular options for my OOB link. Or even >>> a secondary internet circuit either wired or wifi if the DC has that option >>> available. >>> Any good suggestions or experiences with a current OOB solution out there? >>> What are you doing for your OOB management? >>> thanks,Hank >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From ahebert at pubnix.net Mon Feb 24 12:56:01 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 24 Feb 2014 07:56:01 -0500 Subject: The somewhat illegal fix for NTP attacks In-Reply-To: References: <20140222124128.GA24205@gsp.org> Message-ID: <530B4161.5000705@pubnix.net> Well. Since when SNMP, NTP or DNS are vulnerable? They both follow to the appropriate RFC's, contrary to all those AS + /24 that keep allowing spoofing source IP address. The victims of attacks could get the Tiers to follow back the source of the attack instead, but the corporations involved have more money than the small guy you'll bash for having the balls of running a resolver for his roaming customers. This false debate will never end... ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/22/14 16:09, Jimmy Hess wrote: > On Sat, Feb 22, 2014 at 6:41 AM, Rich Kulawiec wrote: > > Perhaps you would rather publish a blacklist of "/24s containing NTP > servers open to MONLIST" over UDP port 123 similar to the bogon feeds. > > And encourage all networks to blackhole the list. > > That way potential NTP reflection abuse traffic gets stuffed as close to > the source as possible. > > > >> It's never appropriate to respond to abuse with abuse. Not only is >> it questionable/unprofessional behavior, but -- as we've seen -- there >> is a high risk that it'll exacerbate the problem, often by targeting >> innocent third parties. >> >> I understand the frustration but this is not the way. >> >> ---rsk > -- > -JH > From Vinny_Abello at Dell.com Mon Feb 24 13:59:57 2014 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Mon, 24 Feb 2014 13:59:57 +0000 Subject: out of band management gear In-Reply-To: <530AC7A9.1020800@bogus.com> References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> <530AC7A9.1020800@bogus.com> Message-ID: Dell - Internal Use - Confidential Just ran into that exact problem with Cisco Nexus 2232TM-E FEX's. They only do 10Gb/1Gb and won't step down to 100Mb. Couldn't connect some newer gear's Ethernet management ports to the management network as a result and have to get a different model FEX like the 2248TP-E just for that. The devices in question are current generation too and only support 100Mb for the management ports. My question was less about why the 2232TM-E's couldn't step down to 100Mb, but rather why in this day and age do we have something that doesn't do 1Gb, even on a management port? -Vinny -----Original Message----- From: joel jaeggli [mailto:joelja at bogus.com] Sent: Sunday, February 23, 2014 11:17 PM To: Randy Carpenter; Richard Hesse Cc: NANOG Subject: Re: out of band management gear On 2/21/14, 12:27 PM, Randy Carpenter wrote: > > OpenGear's newer stuff is Gigabit (SFP even). > > I've not seen any real switch made in the last decade that has a problem with 100Mb/s connections. Ancient cisco, maybe had issues. > there are a substantial number of 10Gb/s switch that cannot do tri-rate on copper sfps. in previous $job oob--ilo-ports doing WOL/ and cdu(s) were the annoying 100Mbs/s only devices. terminal servers (all advocent in this case) made the jump aleady. > thanks, > -Randy > > -- > Randy Carpenter > Vice President - IT Services > First Network Group, Inc. > (800)578-6381, Opt. 1 > http://www.network1.net > http://www.facebook.com/FirstNetworkGroup > > ----- Original Message ----- >> We're really pleased with the Perle IOLAN line. They even have a gigabit >> port without a $10k price tag. Amazing! >> >> It really dumbfounds me why so many vendors are still putting 10/100 >> Ethernet ports on their OOB management (looking at you OpenGear). >> Especially a PITA today since many switchports today don't support links >> speeds less than a gigabit. >> >> -richard >> >> >> On Fri, Feb 21, 2014 at 2:39 PM, Hank Disuko wrote: >> >>> Hi folks, >>> I wonder if anyone has good experiences to share with out-of-band hardware? >>> I'm looking for a good OOB hardware vendor. I need to manage my >>> routers/switches/firewalls in a datacenter located overseas, and I'm >>> looking to setup a good serial console server via an OOB link. >>> I've been looking at Lantronix, OpenGear, Raritan...but they all seem to >>> have the same basic features. I'm having trouble really differentiating >>> them. >>> I'm interested in analog modem, cellular options for my OOB link. Or even >>> a secondary internet circuit either wired or wifi if the DC has that option >>> available. >>> Any good suggestions or experiences with a current OOB solution out there? >>> What are you doing for your OOB management? >>> thanks,Hank >> >> > From jamie at photon.com Mon Feb 24 14:16:11 2014 From: jamie at photon.com (Jamie Bowden) Date: Mon, 24 Feb 2014 14:16:11 +0000 Subject: out of band management gear In-Reply-To: References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> <530AC7A9.1020800@bogus.com> Message-ID: <465966A5F5B867419F604CD3E604C1E55A3127DC@PRA-DCA-MAIL.pra.ray.com> > From: Vinny_Abello at Dell.com [mailto:Vinny_Abello at Dell.com] > Just ran into that exact problem with Cisco Nexus 2232TM-E FEX's. They only > do 10Gb/1Gb and won't step down to 100Mb. Couldn't connect some newer > gear's Ethernet management ports to the management network as a result > and have to get a different model FEX like the 2248TP-E just for that. The > devices in question are current generation too and only support 100Mb for > the management ports. My question was less about why the 2232TM-E's > couldn't step down to 100Mb, but rather why in this day and age do we have > something that doesn't do 1Gb, even on a management port? It's not just you guys at Dell. HP are still doing the same thing with iLO ports (for dedicated iLO ports anyway, shared ports (which are a whole new level of WTF were you thinking?) are normally 1gb and will operate just fine at that connection rate). Jamie From rps at maine.edu Mon Feb 24 14:23:30 2014 From: rps at maine.edu (Ray Soucy) Date: Mon, 24 Feb 2014 09:23:30 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Message-ID: We have had pretty good success in identifying offenders with simple monitoring flow data for NTP flows destined for our address space with packet counts higher than 100; we disable them and notify to correct the configuration on the host. Granted we only service about 1,000 different customers. In cases where a large amount of incoming traffic was generated, we have been able to temporarily blackhole offenders to not saturate smaller downstream connections until traffic levels die down; unfortunately it takes a few days for that to happen, and many service providers outside the US don't seem to be very responsive to their published abuse address. I prefer targeted, temporary, and communicated filtering for actual incidents over blanket filtering for potential incidents. On Sun, Feb 23, 2014 at 7:35 PM, Randy Bush wrote: >> Ive talked to some major peering exchanges and they refuse to take any >> action. Possibly if the requests come from many peering participants >> it will be taken more seriously? > > i have talked to fiber providers and they have refused to take action. > perhaps if requests came from hundreds of the unclued zombies they would > take it seriously. > > randy > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From Vinny_Abello at Dell.com Mon Feb 24 14:42:02 2014 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Mon, 24 Feb 2014 14:42:02 +0000 Subject: out of band management gear In-Reply-To: <465966A5F5B867419F604CD3E604C1E55A3127DC@PRA-DCA-MAIL.pra.ray.com> References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> <530AC7A9.1020800@bogus.com> <465966A5F5B867419F604CD3E604C1E55A3127DC@PRA-DCA-MAIL.pra.ray.com> Message-ID: Dell - Internal Use - Confidential Just to clarify, it wasn't a Dell product I was referring to, but rather the Ethernert management port of a Brocade fibre channel switch... which again, why only 100Mb? Is there that much of a cost difference when mass producing this stuff? Dedicated ports on our iDRACs are 1Gb for OOB on the iDRAC7 (latest generation), but everything prior was 100Mb, I think. Dell does shared ports as well, but I personally always use the dedicated ports. That being said, I have nothing to do with any group in the hardware side of Dell at all. -Vinny -----Original Message----- From: Jamie Bowden [mailto:jamie at photon.com] Sent: Monday, February 24, 2014 9:16 AM To: Abello, Vinny; joelja at bogus.com; rcarpen at network1.net; richard.hesse at weebly.com Cc: nanog at nanog.org Subject: RE: out of band management gear > From: Vinny_Abello at Dell.com [mailto:Vinny_Abello at Dell.com] > Just ran into that exact problem with Cisco Nexus 2232TM-E FEX's. They only > do 10Gb/1Gb and won't step down to 100Mb. Couldn't connect some newer > gear's Ethernet management ports to the management network as a result > and have to get a different model FEX like the 2248TP-E just for that. The > devices in question are current generation too and only support 100Mb for > the management ports. My question was less about why the 2232TM-E's > couldn't step down to 100Mb, but rather why in this day and age do we have > something that doesn't do 1Gb, even on a management port? It's not just you guys at Dell. HP are still doing the same thing with iLO ports (for dedicated iLO ports anyway, shared ports (which are a whole new level of WTF were you thinking?) are normally 1gb and will operate just fine at that connection rate). Jamie From stuarteclark at yahoo.com Mon Feb 24 17:41:16 2014 From: stuarteclark at yahoo.com (stuart clark) Date: Mon, 24 Feb 2014 17:41:16 +0000 (GMT) Subject: Verizon GGC Node Message-ID: <1393263676.48042.YahooMailNeo@web173003.mail.ir2.yahoo.com> Does anyone know how i can connect someone at Verizon in regards to their GGC node i would like to check routing to: 63.88.73.81 (81.73.88.63.ashburn.google-ggc.verizon.com.) NLNOG RING ring-ping script comes back with 91 out of 243 nodes (~37% reachability).? That?s somewhat centered around Europe & North America.? In contrast, any other address I?d usually see 99% reachability from the NLNOG RING. SC. From meirea at charterschoolit.com Mon Feb 24 18:01:06 2014 From: meirea at charterschoolit.com (Mario Eirea) Date: Mon, 24 Feb 2014 18:01:06 +0000 Subject: Miami Dade County Public School VPN Message-ID: Will someone in MDCPS ITS please contact me off list regarding serious VPN disconnection issues that have been plaguing us for the past week? Thank you, Mario Eirea IT Department Layer 8 Solutions 7701 W 26th Ave Unit 2 Hialeah, FL 33016-5603 25.892545?, -80.335783? U.S.A., Earth , Solar System, Milky Way, Local Group, Universe [https://charterschoolit.com/1up_micro.png] [http://charterschoolit.com/layer8_micro.png] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2252 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 6133 bytes Desc: image002.png URL: From LarrySheldon at cox.net Tue Feb 25 01:06:10 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 24 Feb 2014 19:06:10 -0600 Subject: out of band management gear In-Reply-To: References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> <530AC7A9.1020800@bogus.com> Message-ID: <530BEC82.6020708@cox.net> On 2/24/2014 7:59 AM, Vinny_Abello at Dell.com wrote: > Dell - Internal Use - Confidential You sent me this by mistake. I have deleted all of the instances of it that know of. Why does the NANOG forwarder forward these things? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From rdrake at direcpath.com Tue Feb 25 01:08:12 2014 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 24 Feb 2014 20:08:12 -0500 Subject: Atlanta - Patch Cables In-Reply-To: References: Message-ID: <530BECFC.102@direcpath.com> Cables and Kits is local to Atlanta and is great for last minute orders. You can pickup there if needed. http://www.cablesandkits.com/ On 2/21/2014 5:06 AM, Bobby Lacey wrote: > In Atlanta doing an install for a client this weekend and it appears that > the fiber/ethernet patch cables won't be delivered in time from supplier. > Would anyone know of a good resource for patch cables (both fiber and > ethernet) in the metro area? Just wondering if there are any other > resources for these? Frys? > > Offlist please. Thank you! > > Bobby > From sjt5atra at gmail.com Sun Feb 23 23:38:52 2014 From: sjt5atra at gmail.com (sjt5atra) Date: Sun, 23 Feb 2014 18:38:52 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> <530A5A94.7000408@bogus.com> Message-ID: <9DC99918-16AB-418C-B8F1-FC320406A7AD@gmail.com> > On Feb 23, 2014, at 4:39 PM, James Braunegg wrote: > > Dear All > > I released a bit of a blog article last week about filtering NTP request traffic via packet size which might be of interest ! > > So far I known of an unknown tool makes a default request packet of 50 bytes in size > ntpdos.py makes a default request packet of 60 bytes in size > ntp_monlist.py makes a default request packet of 234 bytes in size > monlist from ntpdc makes a default request packet of 234 bytes in size > > In contrast a normal NTP request for a time sync is about 90 bytes in size > > More information and some graphs can be found here http://www.micron21.com/ddos-ntp.php > > Kindest Regards > > > James Braunegg Do these .py's do anything else different to the query packets than "normal" ntp clients? (254TTL instead of the more common 63TTL for "normal" clients.) From mmartinez at getjive.com Mon Feb 24 04:57:12 2014 From: mmartinez at getjive.com (Michael Martinez) Date: Sun, 23 Feb 2014 21:57:12 -0700 Subject: out of band management gear In-Reply-To: <530AC7A9.1020800@bogus.com> References: <1303265085.235458.1393014420975.JavaMail.zimbra@network1.net> <530AC7A9.1020800@bogus.com> Message-ID: Cisco 1921 w/ LTE WAN interface have worked fantastic us. On Sun, Feb 23, 2014 at 9:16 PM, joel jaeggli wrote: > On 2/21/14, 12:27 PM, Randy Carpenter wrote: > > > > OpenGear's newer stuff is Gigabit (SFP even). > > > > I've not seen any real switch made in the last decade that has a problem > with 100Mb/s connections. Ancient cisco, maybe had issues. > > > > there are a substantial number of 10Gb/s switch that cannot do tri-rate > on copper sfps. > > in previous $job oob--ilo-ports doing WOL/ and cdu(s) were the annoying > 100Mbs/s only devices. terminal servers (all advocent in this case) made > the jump aleady. > > > thanks, > > -Randy > > > > -- > > Randy Carpenter > > Vice President - IT Services > > First Network Group, Inc. > > (800)578-6381, Opt. 1 > > http://www.network1.net > > http://www.facebook.com/FirstNetworkGroup > > > > ----- Original Message ----- > >> We're really pleased with the Perle IOLAN line. They even have a gigabit > >> port without a $10k price tag. Amazing! > >> > >> It really dumbfounds me why so many vendors are still putting 10/100 > >> Ethernet ports on their OOB management (looking at you OpenGear). > >> Especially a PITA today since many switchports today don't support links > >> speeds less than a gigabit. > >> > >> -richard > >> > >> > >> On Fri, Feb 21, 2014 at 2:39 PM, Hank Disuko >wrote: > >> > >>> Hi folks, > >>> I wonder if anyone has good experiences to share with out-of-band > hardware? > >>> I'm looking for a good OOB hardware vendor. I need to manage my > >>> routers/switches/firewalls in a datacenter located overseas, and I'm > >>> looking to setup a good serial console server via an OOB link. > >>> I've been looking at Lantronix, OpenGear, Raritan...but they all seem > to > >>> have the same basic features. I'm having trouble really > differentiating > >>> them. > >>> I'm interested in analog modem, cellular options for my OOB link. Or > even > >>> a secondary internet circuit either wired or wifi if the DC has that > option > >>> available. > >>> Any good suggestions or experiences with a current OOB solution out > there? > >>> What are you doing for your OOB management? > >>> thanks,Hank > >> > >> > > > > > -- *Michael Martinez* *IT Operations *- *Network Engineer* | Jive Communications, Inc. Jive.com | 801.804.7078 | mmartinez at getjive.com From brian at brianhouk.com Tue Feb 25 07:52:46 2014 From: brian at brianhouk.com (Brian Houk) Date: Tue, 25 Feb 2014 00:52:46 -0700 Subject: Verizon GGC Node In-Reply-To: <1393263676.48042.YahooMailNeo@web173003.mail.ir2.yahoo.com> References: <1393263676.48042.YahooMailNeo@web173003.mail.ir2.yahoo.com> Message-ID: Hi Stuart, I'm not with Verizon, but if you're having an issue with the cache I may be able to help you out. Feel free to contact me off list. On Mon, Feb 24, 2014 at 10:41 AM, stuart clark wrote: > Does anyone know how i can connect someone at Verizon in regards to their > GGC node i would like to check routing to: 63.88.73.81 ( > 81.73.88.63.ashburn.google-ggc.verizon.com.) > NLNOG RING > ring-ping script comes back with 91 out of 243 nodes (~37% reachability). > That's somewhat centered around Europe & North America. In contrast, > any other address I'd usually see 99% reachability from the NLNOG RING. > > SC. > From blake at ispn.net Tue Feb 25 16:58:00 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 25 Feb 2014 10:58:00 -0600 Subject: Filter NTP traffic by packet size? In-Reply-To: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> Message-ID: <530CCB98.9000701@ispn.net> I talked to one of our upstream IP transit providers and was able to negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP port within our aggregate policer. As mentioned, the legitimate traffic levels of these services are near 0. We gave each service many times the amount to satisfy subscribers, but not enough to overwhelm network links during an attack. --Blake Chris Laffin wrote the following on 2/23/2014 8:58 AM: > Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? > >> On Feb 22, 2014, at 19:23, "Peter Phaal" wrote: >> >> Brocade demonstrated how peering exchanges can selectively filter >> large NTP reflection flows using the sFlow monitoring and hybrid port >> OpenFlow capabilities of their MLXe switches at last week's Network >> Field Day event. >> >> http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html >> >>> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin wrote: >>> Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. >>> >>>> On Feb 22, 2014, at 8:05, "Paul Ferguson" wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >>>>>> >>>>>> On 22/02/2014 09:07, Cb B wrote: >>>>>> Summary IETF response: The problem i described is already solved >>>>>> by bcp38, nothing to see here, carry on with UDP >>>>> udp is here to stay. Denying this is no more useful than trying to >>>>> push the tide back with a teaspoon. >>>> Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage >>>> my competitors to block udp." :-p >>>> >>>> - - ferg >>>> >>>> >>>> - -- >>>> Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS >>>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M >>>> =FTxg >>>> -----END PGP SIGNATURE----- From mstaudinger at corp.earthlink.com Tue Feb 25 17:22:33 2014 From: mstaudinger at corp.earthlink.com (Staudinger, Malcolm) Date: Tue, 25 Feb 2014 17:22:33 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <530CCB98.9000701@ispn.net> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: Why wouldn't you just block chargen entirely? Is it actually still being used these days for anything legitimate? Malcolm Staudinger Information Security Analyst | EIS EarthLink E:?mstaudinger at corp.earthlink.com -----Original Message----- From: Blake Hudson [mailto:blake at ispn.net] Sent: Tuesday, February 25, 2014 8:58 AM To: nanog at nanog.org Subject: Re: Filter NTP traffic by packet size? I talked to one of our upstream IP transit providers and was able to negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP port within our aggregate policer. As mentioned, the legitimate traffic levels of these services are near 0. We gave each service many times the amount to satisfy subscribers, but not enough to overwhelm network links during an attack. --Blake Chris Laffin wrote the following on 2/23/2014 8:58 AM: > Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? > >> On Feb 22, 2014, at 19:23, "Peter Phaal" wrote: >> >> Brocade demonstrated how peering exchanges can selectively filter >> large NTP reflection flows using the sFlow monitoring and hybrid port >> OpenFlow capabilities of their MLXe switches at last week's Network >> Field Day event. >> >> http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_19 >> 86.html >> >>> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin wrote: >>> Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. >>> >>>> On Feb 22, 2014, at 8:05, "Paul Ferguson" wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >>>>>> >>>>>> On 22/02/2014 09:07, Cb B wrote: >>>>>> Summary IETF response: The problem i described is already solved >>>>>> by bcp38, nothing to see here, carry on with UDP >>>>> udp is here to stay. Denying this is no more useful than trying >>>>> to push the tide back with a teaspoon. >>>> Yes, udp is here to stay, and I quote Randy Bush on this, "I >>>> encourage my competitors to block udp." :-p >>>> >>>> - - ferg >>>> >>>> >>>> - -- >>>> Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS >>>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M >>>> =FTxg >>>> -----END PGP SIGNATURE----- From recourse at gmail.com Tue Feb 25 18:49:32 2014 From: recourse at gmail.com (Joseph Jackson) Date: Tue, 25 Feb 2014 12:49:32 -0600 Subject: Verizon FIOS and DSL issues in North Texas Area Message-ID: Hey list, Been seeing issues hitting youtube/wikipedia and other random websites from the north texas area when taking Verizon FIOS and DSL. Haven't been able to narrow it down to any traceroutes or pings as they all seem to be OK. Have reports from other Verizon customers seeing the same issues yesterday and today. Thanks Joseph From nick at foobar.org Tue Feb 25 19:14:54 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 25 Feb 2014 19:14:54 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: <530CEBAE.8030901@foobar.org> On 25/02/2014 17:22, Staudinger, Malcolm wrote: > Why wouldn't you just block chargen entirely? While we're at it, why not just block everything except for tcp port 80 and dns? Isn't that the only legitimate traffic on the interweb these days? Nick From blake at ispn.net Tue Feb 25 20:09:38 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 25 Feb 2014 14:09:38 -0600 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: <530CF882.4020402@ispn.net> As an ISP in the USA, we try to follow the FCC's guidelines on a policy of non blocking. Not just because the FCC says so, but because we think it's in our and our customer's best interests. We don't dictate what our customer's can do with their internet connection as long as they're not breaking the law or negatively affecting the service for others. --Blake Staudinger, Malcolm wrote the following on 2/25/2014 11:22 AM: > Why wouldn't you just block chargen entirely? Is it actually still being used these days for anything legitimate? > > Malcolm Staudinger > Information Security Analyst | EIS > EarthLink > > E: mstaudinger at corp.earthlink.com > > -----Original Message----- > From: Blake Hudson [mailto:blake at ispn.net] > Sent: Tuesday, February 25, 2014 8:58 AM > To: nanog at nanog.org > Subject: Re: Filter NTP traffic by packet size? > > I talked to one of our upstream IP transit providers and was able to negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP port within our aggregate policer. As mentioned, the legitimate traffic levels of these services are near 0. We gave each service many times the amount to satisfy subscribers, but not enough to overwhelm network links during an attack. > > --Blake > From cb.list6 at gmail.com Tue Feb 25 20:52:31 2014 From: cb.list6 at gmail.com (Cb B) Date: Tue, 25 Feb 2014 12:52:31 -0800 Subject: Filter NTP traffic by packet size? In-Reply-To: <530CCB98.9000701@ispn.net> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: On Tue, Feb 25, 2014 at 8:58 AM, Blake Hudson wrote: > I talked to one of our upstream IP transit providers and was able to > negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP > port within our aggregate policer. As mentioned, the legitimate traffic > levels of these services are near 0. We gave each service many times the > amount to satisfy subscribers, but not enough to overwhelm network links > during an attack. > > --Blake > Blake, What you have done is common and required to keep the network up at this time. It is perfectly appropriate to have a baseline and enforce some multiple of the baseline with a policer. People who say this is the wrong thing to do are not running a network of significant size, end of story. CB > Chris Laffin wrote the following on 2/23/2014 8:58 AM: > >> Ive talked to some major peering exchanges and they refuse to take any >> action. Possibly if the requests come from many peering participants it will >> be taken more seriously? >> >>> On Feb 22, 2014, at 19:23, "Peter Phaal" wrote: >>> >>> Brocade demonstrated how peering exchanges can selectively filter >>> large NTP reflection flows using the sFlow monitoring and hybrid port >>> OpenFlow capabilities of their MLXe switches at last week's Network >>> Field Day event. >>> >>> >>> http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html >>> >>>> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin wrote: >>>> Has anyone talked about policing ntp everywhere. Normal traffic levels >>>> are extremely low but the ddos traffic is very high. It would be really cool >>>> if peering exchanges could police ntp on their connected members. >>>> >>>>> On Feb 22, 2014, at 8:05, "Paul Ferguson" >>>>> wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >>>>>>> >>>>>>> On 22/02/2014 09:07, Cb B wrote: >>>>>>> Summary IETF response: The problem i described is already solved >>>>>>> by bcp38, nothing to see here, carry on with UDP >>>>>> >>>>>> udp is here to stay. Denying this is no more useful than trying to >>>>>> push the tide back with a teaspoon. >>>>> >>>>> Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage >>>>> my competitors to block udp." :-p >>>>> >>>>> - - ferg >>>>> >>>>> >>>>> - -- >>>>> Paul Ferguson >>>>> VP Threat Intelligence, IID >>>>> PGP Public Key ID: 0x54DC85B2 >>>>> >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v2.0.22 (MingW32) >>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>> >>>>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS >>>>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M >>>>> =FTxg >>>>> -----END PGP SIGNATURE----- > > > From no.spam at comcast.net Wed Feb 26 12:56:04 2014 From: no.spam at comcast.net (Keegan Holley) Date: Wed, 26 Feb 2014 07:56:04 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com>, <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> On Feb 25, 2014, at 12:22 PM, Staudinger, Malcolm wrote: > Why wouldn't you just block chargen entirely? Is it actually still being used these days for anything legitimate? > More politely stated, it?s not the responsibility of the operator to decide what belongs on the network and what doesn?t. Users can run any services that?s not illegal or even reuse ports for other applications. That being said commonly exploited ports (TCP 25 for example) are often blocked. This is usually done to block or protect an application though not to single out a particular port number. > Malcolm Staudinger > Information Security Analyst | EIS > EarthLink > > E: mstaudinger at corp.earthlink.com > > -----Original Message----- > From: Blake Hudson [mailto:blake at ispn.net] > Sent: Tuesday, February 25, 2014 8:58 AM > To: nanog at nanog.org > Subject: Re: Filter NTP traffic by packet size? > > I talked to one of our upstream IP transit providers and was able to negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP port within our aggregate policer. As mentioned, the legitimate traffic levels of these services are near 0. We gave each service many times the amount to satisfy subscribers, but not enough to overwhelm network links during an attack. > > --Blake > > Chris Laffin wrote the following on 2/23/2014 8:58 AM: >> Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? >> >>> On Feb 22, 2014, at 19:23, "Peter Phaal" wrote: >>> >>> Brocade demonstrated how peering exchanges can selectively filter >>> large NTP reflection flows using the sFlow monitoring and hybrid port >>> OpenFlow capabilities of their MLXe switches at last week's Network >>> Field Day event. >>> >>> http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_19 >>> 86.html >>> >>>> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin wrote: >>>> Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. >>>> >>>>> On Feb 22, 2014, at 8:05, "Paul Ferguson" wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote: >>>>>>> >>>>>>> On 22/02/2014 09:07, Cb B wrote: >>>>>>> Summary IETF response: The problem i described is already solved >>>>>>> by bcp38, nothing to see here, carry on with UDP >>>>>> udp is here to stay. Denying this is no more useful than trying >>>>>> to push the tide back with a teaspoon. >>>>> Yes, udp is here to stay, and I quote Randy Bush on this, "I >>>>> encourage my competitors to block udp." :-p >>>>> >>>>> - - ferg >>>>> >>>>> >>>>> - -- >>>>> Paul Ferguson >>>>> VP Threat Intelligence, IID >>>>> PGP Public Key ID: 0x54DC85B2 >>>>> >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v2.0.22 (MingW32) >>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>> >>>>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS >>>>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M >>>>> =FTxg >>>>> -----END PGP SIGNATURE----- > > From brandon.galbraith at gmail.com Wed Feb 26 17:44:55 2014 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 26 Feb 2014 11:44:55 -0600 Subject: Filter NTP traffic by packet size? In-Reply-To: <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> Message-ID: On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley wrote: > More politely stated, it?s not the responsibility of the operator to decide what belongs on the network and what doesn?t. Users can run any services that?s not illegal or even reuse ports for other applications. That being said commonly exploited ports (TCP 25 for example) are often blocked. This is usually done to block or protect an application though not to single out a particular port number. Don't most residential ISPs already block port 25 outbound? http://www.postcastserver.com/help/Port_25_Blocking.aspx Blocking chargen at the edge doesn't seem to be outside of the realm of possibilities. From jra at baylink.com Wed Feb 26 21:01:50 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 26 Feb 2014 16:01:50 -0500 (EST) Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: Message-ID: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Galbraith" > On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley > wrote: > > More politely stated, it?s not the responsibility of the operator to > > decide what belongs on the network and what doesn?t. Users can run any > > services that?s not illegal or even reuse ports for other > > applications. > Blocking chargen at the edge doesn't seem to be outside of the realm > of possibilities. All of these conversations are variants of "how easy is it to set up a default ACL for loops, and then manage exceptions to it?". Assuming your gear permits it, I don't personally see all that much Bad Actorliness in setting a relatively tight bidirectional ACL for Random Edge Customers, and opening up -- either specific ports, or just "to a less-/un-filtered ACL" on specific request. The question is -- as it is with BCP38 -- *can the edge gear handle it*? And if not: why not? (Protip: because buyers of that gear aren't agitating for it) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From ryanshea at google.com Wed Feb 26 21:22:38 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 26 Feb 2014 16:22:38 -0500 Subject: Managing IOS Configuration Snippets Message-ID: Howdy network operator cognoscenti, I'd love to hear your creative and workable solutions for a way to track in-line the configuration revisions you have on your cisco-like devices. Let me clearify/frame: You have a set of tested/approved configurations for your routers which use IOS style configuration. These configurations of course are always refined and updated. You break these pieces of configuration into logical sections, for example a configuration file for NTP configuration, a file for control plane filter and store these in some revision control system. Put aside for the moment whether this is a reasonable way to comprehend deployed configurations. What methods do some of you use to know which version of a configuration you have deployed to a given router for auditing and update purposes? Remarks are a convenient way to do this for ACLs - but I don't have similar mechanics for top level configurations. About a decade ago I thought I'd be super clever and encode versioning information into the snmp location - but that is just awful and there is a much better way everyone is using, right? Flexible commenting on other vendors/platforms make this a bit easier. Assume that this version encoding perfectly captures what is on the router and that no person is monkeying with the config... version 77 of the control plane filter is the same everywhere. From Valdis.Kletnieks at vt.edu Wed Feb 26 22:33:45 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Feb 2014 17:33:45 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: Your message of "Wed, 26 Feb 2014 11:44:55 -0600." References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> Message-ID: <20125.1393454025@turing-police.cc.vt.edu> On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said: > Blocking chargen at the edge doesn't seem to be outside of the realm of > possibilities. What systems are (a) still have chargen enabled and (b) common enough to make it a viable DDoS vector? Just wondering if I need to go around and find users of mine that need to be smacked around with a large trout.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rdrake at direcpath.com Wed Feb 26 22:37:41 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 26 Feb 2014 17:37:41 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: Message-ID: <530E6CB5.5050403@direcpath.com> On 2/26/2014 4:22 PM, Ryan Shea wrote: > Howdy network operator cognoscenti, > > I'd love to hear your creative and workable solutions for a way to track > in-line the configuration revisions you have on your cisco-like devices. > Let me clearify/frame: > > You have a set of tested/approved configurations for your routers which use > IOS style configuration. These configurations of course are always refined > and updated. You break these pieces of configuration into logical sections, > for example a configuration file for NTP configuration, a file for control > plane filter and store these in some revision control system. Put aside for > the moment whether this is a reasonable way to comprehend deployed > configurations. What methods do some of you use to know which version of a > configuration you have deployed to a given router for auditing and update > purposes? Remarks are a convenient way to do this for ACLs - but I don't > have similar mechanics for top level configurations. About a decade ago I > thought I'd be super clever and encode versioning information into the snmp > location - but that is just awful and there is a much better way everyone > is using, right? Flexible commenting on other vendors/platforms make this a > bit easier. > > Assume that this version encoding perfectly captures what is on the router > and that no person is monkeying with the config... version 77 of the > control plane filter is the same everywhere. > I started a long email that really should just be a blog post. I need to get a blog or something. Short story is this: NETCONF is probably the future of change management on all types of routers and switches. It's not supported everywhere yet and is missing lots of features but they're working on it. Look at the talk given at NANOG60 for more information. There is a puppet module that is also incomplete. I'm not sure this is the right way to go (http://puppetlabs.com/blog/puppet-network-device-management) Most people roll their own solution. If you're looking to do that consider using augeas for parsing the configuration files. It can be really useful for documenting changes, and probably to diff parts of the config. You might also consider rabbitmq or another message queue to handle scheduling and deploying the changes. It can retry failed updates. You should work towards all or nothing commits (not all cisco gear supports this, but you can fake it in a couple of ways. Ultimately you want to rollback to a known good configuration if things go wrong) If you have money and want this right now: Consider looking at Tail-F's NCS, which according to marketing presentations appears to do everything I want right now. I'd like to believe them but I don't have any money so I can't test it out. :) Cheers, Robert From jared at puck.nether.net Wed Feb 26 22:40:06 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 26 Feb 2014 17:40:06 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: <20125.1393454025@turing-police.cc.vt.edu> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> ! <20125.1393454025@turing-police.cc.vt.edu> Message-ID: <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> On Feb 26, 2014, at 5:33 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said: > >> Blocking chargen at the edge doesn't seem to be outside of the realm of >> possibilities. > > What systems are (a) still have chargen enabled and (b) common enough to make > it a viable DDoS vector? Just wondering if I need to go around and find > users of mine that need to be smacked around with a large trout.... First, if you didn't see this excellent paper, check it out: http://www.internetsociety.org/doc/amplification-hell-revisiting-network-protocols-ddos-abuse a) Yes - printers and other devices have it. b) yes. I only ran the scan once, but had ~130k devices respond. http://chargenscan.org/chargenip2asn.txt - Jared From rdrake at direcpath.com Wed Feb 26 22:48:59 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 26 Feb 2014 17:48:59 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: <20125.1393454025@turing-police.cc.vt.edu> References: <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> Message-ID: <530E6F5B.5020008@direcpath.com> On 2/26/2014 5:33 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said: > >> Blocking chargen at the edge doesn't seem to be outside of the realm of >> possibilities. > What systems are (a) still have chargen enabled and (b) common enough to make > it a viable DDoS vector? Just wondering if I need to go around and find > users of mine that need to be smacked around with a large trout.... I would do it. I scanned all my public and private networks and found a few. I've added it to our customer acls to stop it. There were also a couple of internal routers that someone had turned or left it on that were missed. Those are now fixed. nmap -T4 -oG chargen_scan.txt -sS -sU -p 19 From rdrake at direcpath.com Wed Feb 26 22:59:47 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 26 Feb 2014 17:59:47 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <530E6CB5.5050403@direcpath.com> References: <530E6CB5.5050403@direcpath.com> Message-ID: <530E71E3.1040505@direcpath.com> On 2/26/2014 5:37 PM, Robert Drake wrote: > > Most people roll their own solution. If you're looking to do that > consider using augeas for parsing the configuration files. It can be > really useful for documenting changes, and probably to diff parts of > the config. You might also consider rabbitmq or another message queue > to handle scheduling and deploying the changes. It can retry failed > updates. You should work towards all or nothing commits (not all > cisco gear supports this, but you can fake it in a couple of ways. > Ultimately you want to rollback to a known good configuration if > things go wrong) I should amend that even though I recommend all this I haven't used any of it for networking. I guess those are more shiny ball ideas than actual things I've used. We have perl scripts that wrap an in-house API to access our IPAM which generates initial configuration. The template files are a mix of m4 and Template::Toolkit. We use basically one-off perl scripts for auditing sections of the configs to find discrepancies. We use rancid to collect configs. We just started using netdot which is nice for topology discovery. TACACS and DHCP logs are parsed and stored in logstash. All of those tools provide the who, what, where and when but not the why. The why would require a bit more custom stuff and forcing people to use a frontend interface instead of directly touching the routers. We aren't ready for that yet. From ryanshea at google.com Wed Feb 26 23:27:08 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 26 Feb 2014 18:27:08 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <530E71E3.1040505@direcpath.com> References: <530E6CB5.5050403@direcpath.com> <530E71E3.1040505@direcpath.com> Message-ID: Robert - all great suggestions. Big cross-vendor configuration generation and deployment is outside the scope of what I was hoping for here. The goal is to have the version information somehow encoded into the configuration, and I'm not sure that NETCONF has anything to say about that matter. Certainly the same problem of which-versions-are-where exists in the puppet/chef world and there are platform specific ways to answer those questions. Deep analysis of the router configuration itself can give pretty strong hints about which version are deployed, but lets assume full config digestion and comparison is out of the question. From some off-list responses I am hearing that some folks do similar kludges with other text fields, wether they be remark/banner/snmp-foo/interface descriptions. On Wed, Feb 26, 2014 at 5:59 PM, Robert Drake wrote: > > On 2/26/2014 5:37 PM, Robert Drake wrote: > >> >> Most people roll their own solution. If you're looking to do that >> consider using augeas for parsing the configuration files. It can be >> really useful for documenting changes, and probably to diff parts of the >> config. You might also consider rabbitmq or another message queue to >> handle scheduling and deploying the changes. It can retry failed updates. >> You should work towards all or nothing commits (not all cisco gear >> supports this, but you can fake it in a couple of ways. Ultimately you >> want to rollback to a known good configuration if things go wrong) >> > > I should amend that even though I recommend all this I haven't used any of > it for networking. I guess those are more shiny ball ideas than actual > things I've used. We have perl scripts that wrap an in-house API to access > our IPAM which generates initial configuration. The template files are a > mix of m4 and Template::Toolkit. > > We use basically one-off perl scripts for auditing sections of the configs > to find discrepancies. We use rancid to collect configs. We just started > using netdot which is nice for topology discovery. TACACS and DHCP logs are > parsed and stored in logstash. All of those tools provide the who, what, > where and when but not the why. The why would require a bit more custom > stuff and forcing people to use a frontend interface instead of directly > touching the routers. We aren't ready for that yet. > > From morrowc.lists at gmail.com Thu Feb 27 01:57:15 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 26 Feb 2014 20:57:15 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530E6CB5.5050403@direcpath.com> <530E71E3.1040505@direcpath.com> Message-ID: On Wed, Feb 26, 2014 at 6:27 PM, Ryan Shea wrote: > Robert - all great suggestions. Big cross-vendor configuration generation > and deployment is outside the scope of what I was hoping for here. The goal > is to have the version information somehow encoded into the configuration, > and I'm not sure that NETCONF has anything to say about that matter. > Certainly the same problem of which-versions-are-where exists in the > puppet/chef world and there are platform specific ways to answer those puppet solves this by comparing a complete md5(file) with deployed md5(file)... not as simple to do that on: access-list 150 permit icmp any any access-list 150 permit tcp any eq 80 any access-list 150 deny ip any any it'd be super nice if you could grab out just the hermetic bit of config you care about, and md5sum() that, eh? provided your stored config was written out in the IOS version (specific?) spacing/etc manner, of course. > questions. Deep analysis of the router configuration itself can give pretty > strong hints about which version are deployed, but lets assume full config > digestion and comparison is out of the question. From some off-list > responses I am hearing that some folks do similar kludges with other text > fields, wether they be remark/banner/snmp-foo/interface descriptions. this makes me sad... but go 'state of the art network equipment!' is it time to start asking vendors for more operable configuration storage and access? From hhoffman at ip-solutions.net Thu Feb 27 02:01:29 2014 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 26 Feb 2014 21:01:29 -0500 Subject: Filter NTP traffic by packet size? Message-ID: <20140227020131.52CFA70FA9@b-sasl-quonix.pobox.com> Most of what I've seen are reset configs on network gear, standalone devices (printers), and the occasional win 98 box with network addons. We put blocks in place for ntp, SNMP for a short time to get things under control. Chargen was so small it was easier to just alert folks directly. HTH. Cheers, Harry On Feb 26, 2014 5:33 PM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said: > > > Blocking chargen at the edge doesn't seem to be outside of the realm of > > possibilities. > > What systems are (a) still have chargen enabled and (b) common enough to make > it a viable DDoS vector?? Just wondering if I need to go around and find > users of mine that need to be smacked around with a large trout.... From mysidia at gmail.com Thu Feb 27 04:03:43 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 26 Feb 2014 22:03:43 -0600 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: On Tue, Feb 25, 2014 at 11:22 AM, Staudinger, Malcolm < mstaudinger at corp.earthlink.com> wrote: > Why wouldn't you just block chargen entirely? Is it actually still being > used these days for anything legitimate? > Long term blocking based on port number is sure to result in problems. It's more appropriate to block chargen to a source shown to be subject to abuse. Simply blocking port 19 globally could very well be interfering with other use and disrupting connectivity for other applications not related to chargen, that just so happen to use Port # 19 as an endpoint. Thanks to the wonder that is SRV records, users MAY and, are technically quite free to, and sometimes do locate critical services on arbitrary --- alternative port numbers, such as perhaps port 19, using the DNS SRV response; instead of having clients locate the port number by relying upon a well-known port registration with IANA. In this case, policing or discarding port 19 traffic to hosts that do not use port 19 for chargen, is a connectivity disruption. Among known hosts that agree to communicate on port #19 without requiring a port registration, port number 19 may be used for any purpose, not necessarily chargen related. The same goes for port 123, 25, etc; both UDP and TCP. Although the port is not in the traditional ephemeral range, nothing precludes its use as an ephmeral port for various application functions, either. The "well known port" assignments are advisory or recommended, for use by other unknown processes. the purpose of well known port assignments is for service location; the port number is not a sequence of application identification bits. The QUIC protocol using port 80/udp, was a great example of a different application using a well-known port address, besides the one that would appear as the well-known port registration. > Malcolm Staudinger > Information Security Analyst | EIS > EarthLink > > E: mstaudinger at corp.earthlink.com > -- -JH From randy at psg.com Thu Feb 27 05:09:47 2014 From: randy at psg.com (Randy Bush) Date: Thu, 27 Feb 2014 05:09:47 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> Message-ID: > I only ran the scan once, but had ~130k devices respond. is there any modern utility in chargen? From rdrake at direcpath.com Thu Feb 27 05:42:16 2014 From: rdrake at direcpath.com (Robert Drake) Date: Thu, 27 Feb 2014 00:42:16 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> Message-ID: <530ED038.9030602@direcpath.com> On 2/26/2014 11:03 PM, Jimmy Hess wrote: > > The "well known port" assignments are advisory or recommended, for use by > other unknown processes. the purpose of well known port > assignments is for service location; the port number is not a sequence of > application identification bits. > > > The QUIC protocol using port 80/udp, was a great example of a different > application using a well-known port address, besides > the one that would appear as the well-known port registration. > > Sometimes bypassing IANA for port registration works in your favor, sometimes it doesn't. Of course there should be a way to setup connections that aren't listed in IANA, but using well-known low ports isn't safe. It's biting us and we've got to counter it. UDP doesn't do enough setup on a connection for you to really figure out if it's chargen or some new traffic type. Even if you have the luxury of putting a stateful firewall in a place and filtering based on what traffic is there, the only valid choice for an ISP would be to say "permit only the registered service chargen on port 19, oh, and block it anyway because nobody should be using chargen." Taking the high road about blocking services was an option 10 years ago. The gear couldn't do it and most internet users were still somewhat tech savvy. The landscape has changed. I can't convince my cousin not to click on ransomware. I think my only viable option is to filter residential customers for their own good, and if someone actually wants/needs one of these ports opened then we can work with them.* * ISPs have also reduced their abuse staffing by blocking port 25. It's either that or just acknowledge that you won't be able to process all your abuse emails because there are too many people spamming/too many compromised machines. So in some ways it's a financial need for us to block even more aggressively than big ISPs because we can't afford to staff abuse for things that are automatically fixable. From geier at geier.ne.tz Thu Feb 27 05:46:48 2014 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 27 Feb 2014 08:46:48 +0300 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> Message-ID: <530ED148.3030305@geier.ne.tz> On 2/27/2014 8:09 AM, Randy Bush wrote: >> I only ran the scan once, but had ~130k devices respond. > > is there any modern utility in chargen? I know of none, maybe I'm too young. So we could conclude we don't need that service running. But some folk use ports for services other than the intended - like tcp:443 for VPN ;-) So if we can get enough abusable end-systems fixed (hope so *), and we get enough source address validation (bcp38) to reduce sources of badness (hope so *), then the network won't need to block that port and someone can make inventive use of it ;-) (*) and working on it. Frank PS: - seems something going on already, had one outside complain about traffic from our IP udp:19 - better start scanning proactively From mysidia at gmail.com Thu Feb 27 06:06:44 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 27 Feb 2014 00:06:44 -0600 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> Message-ID: On Wed, Feb 26, 2014 at 11:09 PM, Randy Bush wrote: > > I only ran the scan once, but had ~130k devices respond. > is there any modern utility in chargen? > Does ne'er-do-wells hitting IRC users with "DCC CHAT" requests targeted to trick the victim into connecting to port 19/tcp count as a modern use? I remember, that was a dirty trick in the late '90s, that would today be called a DoS, since the result was to crash desktop chat software ----- nonetheless, it's the only thing I heard of anyone using chargen for until recently. Well, if you enable chargen on a large number of hostst and directed broadcasts: an artificially created chargen storm could be one way to stres-test a WAN link, or to help validate QoS prioritization. Chargen's supposed to be a useful measurement and debugging tool, for developing a TCP/IP stack. I think it has little use nowadays, and there are some more sophisticated tools around today. I would say chargen may have some utility, but it should not be a service turned on, provided, or offered outside the secure confines of a testing lab. In other words: chargen for testeing in a lab, sure. Chargen on production devices, when connected to the public internet: bad idea -- -JH From mark.tinka at seacom.mu Thu Feb 27 07:45:34 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Feb 2014 09:45:34 +0200 Subject: Managing IOS Configuration Snippets In-Reply-To: References: Message-ID: <201402270945.37748.mark.tinka@seacom.mu> We are evaluating a piece of software called Skybox: http://www.skyboxsecurity.com/ It's geared to security analytics, but it does allow you to define configurations that are expected on a device, what software version it is running, whether commands that aren't there are, and those that should be there aren't, e.t.c. It supports all major network equipment vendors, and also allows for simple or complex regular expressions that can be used to search configuration files more easily. It is an offline system, so all you do is regularly present it with a text file of the device's running configuration, and it will do the necessary checks per the policy you have defined. Based on the configuration files it has, it can also create a visual model of your network. Not something you'd rely on given you have other tools for that, but kind of cool, nonetheless. Worth a look, I'd say. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From lathama at gmail.com Thu Feb 27 11:52:43 2014 From: lathama at gmail.com (Andrew Latham) Date: Thu, 27 Feb 2014 05:52:43 -0600 Subject: Managing IOS Configuration Snippets In-Reply-To: References: Message-ID: For a large install I set up a solution that might help. I utilized a Mediawiki install and its API to create, update and pull the configuration on many IOS devices. A wiki page for the host name was dynamically created and the configuration was placed there daily or hourly. This allowed support to review the configuration and advise customers quicker. Additional hacks for updating the devices via the wiki were used. The goal was transparency for the support team and the side effect was wiki page history showing what day and what lines changed. As mentioned the answer to your question would likely make a good article. On Wed, Feb 26, 2014 at 3:22 PM, Ryan Shea wrote: > Howdy network operator cognoscenti, > > I'd love to hear your creative and workable solutions for a way to track > in-line the configuration revisions you have on your cisco-like devices. > Let me clearify/frame: > > You have a set of tested/approved configurations for your routers which use > IOS style configuration. These configurations of course are always refined > and updated. You break these pieces of configuration into logical sections, > for example a configuration file for NTP configuration, a file for control > plane filter and store these in some revision control system. Put aside for > the moment whether this is a reasonable way to comprehend deployed > configurations. What methods do some of you use to know which version of a > configuration you have deployed to a given router for auditing and update > purposes? Remarks are a convenient way to do this for ACLs - but I don't > have similar mechanics for top level configurations. About a decade ago I > thought I'd be super clever and encode versioning information into the snmp > location - but that is just awful and there is a much better way everyone > is using, right? Flexible commenting on other vendors/platforms make this a > bit easier. > > Assume that this version encoding perfectly captures what is on the router > and that no person is monkeying with the config... version 77 of the > control plane filter is the same everywhere. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From hhoffman at ip-solutions.net Thu Feb 27 12:44:35 2014 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 27 Feb 2014 07:44:35 -0500 Subject: Managing IOS Configuration Snippets Message-ID: <20140227124439.3DF626CD24@b-sasl-quonix.pobox.com> Wow, this sounds fantastic! Have any code you can share? Cheers, Harry On Feb 27, 2014 6:52 AM, Andrew Latham wrote: > > For a large install I set up a solution that might help. I utilized a > Mediawiki install and its API to create, update and pull the > configuration on many IOS devices. A wiki page for the host name was > dynamically created and the configuration was placed there daily or > hourly. This allowed support to review the configuration and advise > customers quicker. Additional hacks for updating the devices via the > wiki were used. The goal was transparency for the support team and the > side effect was wiki page history showing what day and what lines > changed.? As mentioned the answer to your question would likely make a > good article. > > On Wed, Feb 26, 2014 at 3:22 PM, Ryan Shea wrote: > > Howdy network operator cognoscenti, > > > > I'd love to hear your creative and workable solutions for a way to track > > in-line the configuration revisions you have on your cisco-like devices. > > Let me clearify/frame: > > > > You have a set of tested/approved configurations for your routers which use > > IOS style configuration. These configurations of course are always refined > > and updated. You break these pieces of configuration into logical sections, > > for example a configuration file for NTP configuration, a file for control > > plane filter and store these in some revision control system. Put aside for > > the moment whether this is a reasonable way to comprehend deployed > > configurations. What methods do some of you use to know which version of a > > configuration you have deployed to a given router for auditing and update > > purposes? Remarks are a convenient way to do this for ACLs - but I don't > > have similar mechanics for top level configurations. About a decade ago I > > thought I'd be super clever and encode versioning information into the snmp > > location - but that is just awful and there is a much better way everyone > > is using, right? Flexible commenting on other vendors/platforms make this a > > bit easier. > > > > Assume that this version encoding perfectly captures what is on the router > > and that no person is monkeying with the config... version 77 of the > > control plane filter is the same everywhere. > > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > From ryanshea at google.com Thu Feb 27 12:45:47 2014 From: ryanshea at google.com (Ryan Shea) Date: Thu, 27 Feb 2014 07:45:47 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: Message-ID: To clarify a bit, systems to grab or store the running config or keep track of intent. Let's assume that comparing the deployed configuration of an individual device to intent derived from a bunch of configuration bits from an RCS system is *hard*. For example, let's say you have a vty configuration which has a couple sections, line vty 0 2 and line vty 3 5. Someone updates this configuration in your RCS which removes the access-class from line vty 0 2 and adds it to the access-class for line vty 3 5. Let's also assume that you have *lots* of devices and *lots* of configurations and you cannot reasonably egrep/regexp your way to success here. I thank you all for your responses. I was hoping that someone trick I was not seeing and would say "oh, you just need to do..." On Thu, Feb 27, 2014 at 6:52 AM, Andrew Latham wrote: > For a large install I set up a solution that might help. I utilized a > Mediawiki install and its API to create, update and pull the > configuration on many IOS devices. A wiki page for the host name was > dynamically created and the configuration was placed there daily or > hourly. This allowed support to review the configuration and advise > customers quicker. Additional hacks for updating the devices via the > wiki were used. The goal was transparency for the support team and the > side effect was wiki page history showing what day and what lines > changed. As mentioned the answer to your question would likely make a > good article. > > On Wed, Feb 26, 2014 at 3:22 PM, Ryan Shea wrote: > > Howdy network operator cognoscenti, > > > > I'd love to hear your creative and workable solutions for a way to track > > in-line the configuration revisions you have on your cisco-like devices. > > Let me clearify/frame: > > > > You have a set of tested/approved configurations for your routers which > use > > IOS style configuration. These configurations of course are always > refined > > and updated. You break these pieces of configuration into logical > sections, > > for example a configuration file for NTP configuration, a file for > control > > plane filter and store these in some revision control system. Put aside > for > > the moment whether this is a reasonable way to comprehend deployed > > configurations. What methods do some of you use to know which version of > a > > configuration you have deployed to a given router for auditing and update > > purposes? Remarks are a convenient way to do this for ACLs - but I don't > > have similar mechanics for top level configurations. About a decade ago I > > thought I'd be super clever and encode versioning information into the > snmp > > location - but that is just awful and there is a much better way everyone > > is using, right? Flexible commenting on other vendors/platforms make > this a > > bit easier. > > > > Assume that this version encoding perfectly captures what is on the > router > > and that no person is monkeying with the config... version 77 of the > > control plane filter is the same everywhere. > > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > From contact at winterei.se Thu Feb 27 12:52:08 2014 From: contact at winterei.se (Paul S.) Date: Thu, 27 Feb 2014 21:52:08 +0900 Subject: Managing IOS Configuration Snippets In-Reply-To: <20140227124439.3DF626CD24@b-sasl-quonix.pobox.com> References: <20140227124439.3DF626CD24@b-sasl-quonix.pobox.com> Message-ID: <530F34F8.90201@winterei.se> Rancid with the git plugin can be used to attain pretty much the exact same thing a lot more easily, if you're after an existing implementation of it. Cheers, Paul On 2/27/2014 ?? 09:44, Harry Hoffman wrote: > Wow, this sounds fantastic! Have any code you can share? > > Cheers, > Harry > > On Feb 27, 2014 6:52 AM, Andrew Latham wrote: >> For a large install I set up a solution that might help. I utilized a >> Mediawiki install and its API to create, update and pull the >> configuration on many IOS devices. A wiki page for the host name was >> dynamically created and the configuration was placed there daily or >> hourly. This allowed support to review the configuration and advise >> customers quicker. Additional hacks for updating the devices via the >> wiki were used. The goal was transparency for the support team and the >> side effect was wiki page history showing what day and what lines >> changed. As mentioned the answer to your question would likely make a >> good article. >> >> On Wed, Feb 26, 2014 at 3:22 PM, Ryan Shea wrote: >>> Howdy network operator cognoscenti, >>> >>> I'd love to hear your creative and workable solutions for a way to track >>> in-line the configuration revisions you have on your cisco-like devices. >>> Let me clearify/frame: >>> >>> You have a set of tested/approved configurations for your routers which use >>> IOS style configuration. These configurations of course are always refined >>> and updated. You break these pieces of configuration into logical sections, >>> for example a configuration file for NTP configuration, a file for control >>> plane filter and store these in some revision control system. Put aside for >>> the moment whether this is a reasonable way to comprehend deployed >>> configurations. What methods do some of you use to know which version of a >>> configuration you have deployed to a given router for auditing and update >>> purposes? Remarks are a convenient way to do this for ACLs - but I don't >>> have similar mechanics for top level configurations. About a decade ago I >>> thought I'd be super clever and encode versioning information into the snmp >>> location - but that is just awful and there is a much better way everyone >>> is using, right? Flexible commenting on other vendors/platforms make this a >>> bit easier. >>> >>> Assume that this version encoding perfectly captures what is on the router >>> and that no person is monkeying with the config... version 77 of the >>> control plane filter is the same everywhere. >> >> >> -- >> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ >> From saku at ytti.fi Thu Feb 27 13:58:58 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 27 Feb 2014 15:58:58 +0200 Subject: Managing IOS Configuration Snippets In-Reply-To: <530E6CB5.5050403@direcpath.com> References: <530E6CB5.5050403@direcpath.com> Message-ID: <20140227135858.GB3236@pob.ytti.fi> On (2014-02-26 17:37 -0500), Robert Drake wrote: > Consider looking at Tail-F's NCS, which according to marketing > presentations appears to do everything I want right now. I'd like > to believe them but I don't have any money so I can't test it out. > :) Tail-F is probably least bad option out there. In configuration management, this is super easy: DB => Template => Network This is super hard: Network => DB The first one keeps all platform specific logic in flat ascii files filled with variables from template. When you introduce new product, feature, vendor to network, you only add new ascii templates, extremely easy, no platform-specific logic in DB. The second one every little change in network, requires parser changes trying to model it back to DB. This is not sustainable. We can kid ourselves that NetCONF/YANG will solve this, but they won't. SNMP is old technology, when new feature comes to vendor, it may take _years_ before MIB comes. There is no reason to suspect you will be able to get feature out via NetCONF just because it is there. And if you can't do it 100% then you have to write parser which can understand it. You only need the second one, in case 100% is not from DB. But it is actually trivial to produce 100% from DB. You don't want DB to model base configuration, that's lot of work for no gain, that'll come from template or at most DB vendor-specific-blob. Then after you push configuration from DB to network, you immediately collect configuration and create relation of DB-config 2 network-config, now you can keep ensuring network has correct config. If it does not have, you don't know why not, you can't fix the error itself, but you can repovision whole box, so you do get configuration conformance check, it's just very crude. But the alternative, trying to understand network config, is just never ending path to to pain. If someone is going to do it, model it to python or ruby ORM and put it in github so others can contribute and we don't need to do it alone. -- ++ytti From tdurack at gmail.com Thu Feb 27 14:36:54 2014 From: tdurack at gmail.com (Tim Durack) Date: Thu, 27 Feb 2014 09:36:54 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <20140227135858.GB3236@pob.ytti.fi> References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: On Thu, Feb 27, 2014 at 8:58 AM, Saku Ytti wrote: > On (2014-02-26 17:37 -0500), Robert Drake wrote: > > > Consider looking at Tail-F's NCS, which according to marketing > > presentations appears to do everything I want right now. I'd like > > to believe them but I don't have any money so I can't test it out. > > :) > > Tail-F is probably least bad option out there. > > In configuration management, this is super easy: > > DB => Template => Network > > This is super hard: > > Network => DB > > > The first one keeps all platform specific logic in flat ascii files filled > with variables from template. > When you introduce new product, feature, vendor to network, you only add > new > ascii templates, extremely easy, no platform-specific logic in DB. > > The second one every little change in network, requires parser changes > trying > to model it back to DB. This is not sustainable. We can kid ourselves that > NetCONF/YANG will solve this, but they won't. SNMP is old technology, when > new > feature comes to vendor, it may take _years_ before MIB comes. There is no > reason to suspect you will be able to get feature out via NetCONF just > because > it is there. And if you can't do it 100% then you have to write parser > which > can understand it. > > You only need the second one, in case 100% is not from DB. But it is > actually > trivial to produce 100% from DB. You don't want DB to model base > configuration, that's lot of work for no gain, that'll come from template > or > at most DB vendor-specific-blob. > Then after you push configuration from DB to network, you immediately > collect > configuration and create relation of DB-config 2 network-config, now you > can > keep ensuring network has correct config. If it does not have, you don't > know > why not, you can't fix the error itself, but you can repovision whole box, > so > you do get configuration conformance check, it's just very crude. > > But the alternative, trying to understand network config, is just never > ending > path to to pain. If someone is going to do it, model it to python or ruby > ORM > and put it in github so others can contribute and we don't need to do it > alone. > > -- > ++ytti > > Agree with this. We started out with rancid, quickly moved to a homebrew scp and git backed system with webgit/cgit as the user interface. If you are lucky your network equipment supports "advanced features" like ssh keys. If not, you might be stuck using sshpass to ease config collection. Built a config parsing system that would decompose monolithic configs into configlet files. Md5sum the file and use as part of the filename. You can then see "version" information for parts of the config tree. Quickly realized that maintaining this system is a full time job, due to the advanced status of network equipment software... Now looking at Tail-F NCS. Demo is impressive. I'm hopeful. Stating the obvious: the software running on most network equipment is of poor quality. The tools to manage this are a combination of high quality engineers and homebrew tools. Vendor tools are of a similar quality to the equipment software. I'd like to think "SDN" is an attempt to improve this, but I have my doubts. -- Tim:> From ryanshea at google.com Thu Feb 27 14:38:33 2014 From: ryanshea at google.com (Ryan Shea) Date: Thu, 27 Feb 2014 09:38:33 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <20140227135858.GB3236@pob.ytti.fi> References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: We've gone off the rails a bit here. The 'in-line' bit was really at the heart of my question. With the number of responses so far it's starting to sound like there is not an answer other than kludge. "workable solutions for a way to track *in-line* the configuration revisions you have on your cisco-like devices" This could be on brocade/hp/arista/ios, so "ask the vendor to..." is not a (short term) solution. Assume we've got rancid-git, super awesome network engineers who write configuration bits and test and review them, and a super dooper tempating config pushy tool with retries and a blinky dashboard. Now, I hand you the 'show run' output and ask you if version 77 of the vty config is on this device. Can you answer the question? Now I hand you the 'show run' from 10,000 more device configs - and 100 more configuration chunks from revision control. Can you still answer the question? Assume a magical revision-history-aware configuration cross reference parser (while a noble and lovely goal) is not available. On Thu, Feb 27, 2014 at 8:58 AM, Saku Ytti wrote: > On (2014-02-26 17:37 -0500), Robert Drake wrote: > > > Consider looking at Tail-F's NCS, which according to marketing > > presentations appears to do everything I want right now. I'd like > > to believe them but I don't have any money so I can't test it out. > > :) > > Tail-F is probably least bad option out there. > > In configuration management, this is super easy: > > DB => Template => Network > > This is super hard: > > Network => DB > > > The first one keeps all platform specific logic in flat ascii files filled > with variables from template. > When you introduce new product, feature, vendor to network, you only add > new > ascii templates, extremely easy, no platform-specific logic in DB. > > The second one every little change in network, requires parser changes > trying > to model it back to DB. This is not sustainable. We can kid ourselves that > NetCONF/YANG will solve this, but they won't. SNMP is old technology, when > new > feature comes to vendor, it may take _years_ before MIB comes. There is no > reason to suspect you will be able to get feature out via NetCONF just > because > it is there. And if you can't do it 100% then you have to write parser > which > can understand it. > > You only need the second one, in case 100% is not from DB. But it is > actually > trivial to produce 100% from DB. You don't want DB to model base > configuration, that's lot of work for no gain, that'll come from template > or > at most DB vendor-specific-blob. > Then after you push configuration from DB to network, you immediately > collect > configuration and create relation of DB-config 2 network-config, now you > can > keep ensuring network has correct config. If it does not have, you don't > know > why not, you can't fix the error itself, but you can repovision whole box, > so > you do get configuration conformance check, it's just very crude. > > But the alternative, trying to understand network config, is just never > ending > path to to pain. If someone is going to do it, model it to python or ruby > ORM > and put it in github so others can contribute and we don't need to do it > alone. > > -- > ++ytti > > From ryanshea at google.com Thu Feb 27 14:50:06 2014 From: ryanshea at google.com (Ryan Shea) Date: Thu, 27 Feb 2014 09:50:06 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: A couple more thoughts, regarding Network => DB I completely agree that trying to use the network config itself as the authority for what we intend to be on a device is not the right long-term approach. There is still a problem with Network => DB that I see. Assuming you have *many* devices, that may or may not be up at a given time, or may be in various stages of turn-up / burn-in / decom it is expected that a config change will not successfully make it to all devices. There are other timing issues, like a config built for a device being turned up, followed by a push of an update to all devices that "succeeds", followed by the final turn-up of this device. Even if you have a fancy config pushing engine, let's just take as a given that you'll need to scrub through your rancid-git backups to determine what needs to be updated. Regarding the MD5 approach, let's also think that configlets could have "no" commands in them. In the NTP example I had before, if we wanted to remove an NTP server the configlet would need the "no" version, but the rancid backup obviously would not have this. I'm not trying to work a unit test assertion framework here either. Some vendors have more robust commenting, and this can be quite convenient for explicitly stating what was pushed to the device. What are you using in your network... banner, snmp-location, hope, prayer? On Thu, Feb 27, 2014 at 9:36 AM, Tim Durack wrote: > On Thu, Feb 27, 2014 at 8:58 AM, Saku Ytti wrote: > > > On (2014-02-26 17:37 -0500), Robert Drake wrote: > > > > > Consider looking at Tail-F's NCS, which according to marketing > > > presentations appears to do everything I want right now. I'd like > > > to believe them but I don't have any money so I can't test it out. > > > :) > > > > Tail-F is probably least bad option out there. > > > > In configuration management, this is super easy: > > > > DB => Template => Network > > > > This is super hard: > > > > Network => DB > > > > > > The first one keeps all platform specific logic in flat ascii files > filled > > with variables from template. > > When you introduce new product, feature, vendor to network, you only add > > new > > ascii templates, extremely easy, no platform-specific logic in DB. > > > > The second one every little change in network, requires parser changes > > trying > > to model it back to DB. This is not sustainable. We can kid ourselves > that > > NetCONF/YANG will solve this, but they won't. SNMP is old technology, > when > > new > > feature comes to vendor, it may take _years_ before MIB comes. There is > no > > reason to suspect you will be able to get feature out via NetCONF just > > because > > it is there. And if you can't do it 100% then you have to write parser > > which > > can understand it. > > > > You only need the second one, in case 100% is not from DB. But it is > > actually > > trivial to produce 100% from DB. You don't want DB to model base > > configuration, that's lot of work for no gain, that'll come from template > > or > > at most DB vendor-specific-blob. > > Then after you push configuration from DB to network, you immediately > > collect > > configuration and create relation of DB-config 2 network-config, now you > > can > > keep ensuring network has correct config. If it does not have, you don't > > know > > why not, you can't fix the error itself, but you can repovision whole > box, > > so > > you do get configuration conformance check, it's just very crude. > > > > But the alternative, trying to understand network config, is just never > > ending > > path to to pain. If someone is going to do it, model it to python or ruby > > ORM > > and put it in github so others can contribute and we don't need to do it > > alone. > > > > -- > > ++ytti > > > > > Agree with this. > > We started out with rancid, quickly moved to a homebrew scp and git backed > system with webgit/cgit as the user interface. If you are lucky your > network equipment supports "advanced features" like ssh keys. If not, you > might be stuck using sshpass to ease config collection. > > Built a config parsing system that would decompose monolithic configs into > configlet files. Md5sum the file and use as part of the filename. You can > then see "version" information for parts of the config tree. Quickly > realized that maintaining this system is a full time job, due to the > advanced status of network equipment software... > > Now looking at Tail-F NCS. Demo is impressive. I'm hopeful. > > Stating the obvious: the software running on most network equipment is of > poor quality. The tools to manage this are a combination of high quality > engineers and homebrew tools. Vendor tools are of a similar quality to the > equipment software. I'd like to think "SDN" is an attempt to improve this, > but I have my doubts. > > -- > Tim:> > From tdurack at gmail.com Thu Feb 27 16:50:28 2014 From: tdurack at gmail.com (Tim Durack) Date: Thu, 27 Feb 2014 11:50:28 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea wrote: > A couple more thoughts, regarding > > Network => DB > > I completely agree that trying to use the network config itself as the > authority for what we intend to be on a device is not the right long-term > approach. There is still a problem with Network => DB that I see. Assuming > you have *many* devices, that may or may not be up at a given time, or may > be in various stages of turn-up / burn-in / decom it is expected that a > config change will not successfully make it to all devices. There are other > timing issues, like a config built for a device being turned up, followed > by a push of an update to all devices that "succeeds", followed by the > final turn-up of this device. Even if you have a fancy config pushing > engine, let's just take as a given that you'll need to scrub through your > rancid-git backups to determine what needs to be updated. > > Regarding the MD5 approach, let's also think that configlets could have > "no" commands in them. In the NTP example I had before, if we wanted to > remove an NTP server the configlet would need the "no" version, but the > rancid backup obviously would not have this. I'm not trying to work a unit > test assertion framework here either. Some vendors have more robust > commenting, and this can be quite convenient for explicitly stating what > was pushed to the device. What are you using in your network... banner, > snmp-location, hope, prayer? > We don't do this, but the only flexible commenting in IOS style configs is ACLs. You could have an ACL that contains remarks only, and include version information: ip access-list CFG-VER remark CFG-VER-NTP 1.0.3 remark CFG-VER-VTY 4.3.2 end You could break this into individual ACLs if you prefer: ip access-list CFG-VER-NTP remark CFG-VER-NTP 1.0.3 end ip access-list CFG-VER-VTY remark CFG-VER-VTY 4.3.2 end Seems ridiculous, but that is the sorry state of the network OS. -- Tim:> From saku at ytti.fi Thu Feb 27 17:01:01 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 27 Feb 2014 19:01:01 +0200 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: <20140227170101.GA28082@pob.ytti.fi> On (2014-02-27 09:50 -0500), Ryan Shea wrote: > Regarding the MD5 approach, let's also think that configlets could have > "no" commands in them. In the NTP example I had before, if we wanted to For DB => Template => Network it's to me very easy, but yes, each template you make must have anti-template version. So let's say you have NTP model, which may contain some access restriction information, NTP version, NTP peers. When you apply this model to device, then some platform specific ntp template is called. If you remove this from device, you need to call 'anti' version of the template. Very simple and easy. You also wondered how do I know which version of config network device has, this is hard problem. To know exactly what is wrong and how to address just that. If you can relax requirement to know if configuration is correct or incorrect it becomes trivial. But fixing incorrect is either full reprovision of new config (at least in IOS and JunOS not a problem, won't break the unchanged bits). Or you have human resolve it (of course as custom dictates first you punish the responsible severely but swiftly) -- ++ytti From erikm at buh.org Thu Feb 27 17:04:57 2014 From: erikm at buh.org (Erik Muller) Date: Thu, 27 Feb 2014 12:04:57 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: Message-ID: <530F7039.4050703@buh.org> On 2/26/14, 16:22 , Ryan Shea wrote: > Howdy network operator cognoscenti, > > I'd love to hear your creative and workable solutions for a way to track > in-line the configuration revisions you have on your cisco-like devices. ... > > Assume that this version encoding perfectly captures what is on the router > and that no person is monkeying with the config... version 77 of the > control plane filter is the same everywhere. At a previous job, our roll-your-own solution was a template based system(*) generating full configs; all the version history for template sections, per-router local tweaks, and generated results was kept in RCS, and the actual last-configured version, plus any incremental changes, was kept in the login banner. So at login you'd see something like: blah blah authorized users blah blah $Id: routername-confg,v 1.23 2013/08/20 03:07:16 username Exp INCR: 1.2,1.3,1.4,1.5,1.6 and that version tracking made its way through to rancid for easy offline auditing. This made it nice and easy to tell when and what had been updated, though it still would take a couple steps to identify what exact subsections had been changed over time (since the incremental version tags were specific deltas in per-device configurations. You could probably do it in a more global way too - git commit ids, maybe? - but you also don't want to make the version string too wordy either). -e * based on ftp://ftp.cac.washington.edu/pub/config-generator/, but substantially enhanced beyond the last public domain version. I know I'd be really happy if the current version was ever open-sourced... From ops.lists at gmail.com Thu Feb 27 17:21:34 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 27 Feb 2014 22:51:34 +0530 Subject: Managing IOS Configuration Snippets In-Reply-To: <530F7039.4050703@buh.org> References: <530F7039.4050703@buh.org> Message-ID: On Thu, Feb 27, 2014 at 10:34 PM, Erik Muller wrote: > At a previous job, our roll-your-own solution was a template based system(*) > generating full configs; all the version history for template sections, > per-router local tweaks, and generated results was kept in RCS, and the > actual last-configured version, plus any incremental changes, was kept in > the login banner. This has been around for several years now - http://sourceforge.net/projects/cisco-conf-rep/ -- Suresh Ramasubramanian (ops.lists at gmail.com) From chuckchurch at gmail.com Thu Feb 27 17:34:01 2014 From: chuckchurch at gmail.com (Chuck Church) Date: Thu, 27 Feb 2014 12:34:01 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530E6CB5.5050403@direcpath.com> <20140227135858.GB3236@pob.ytti.fi> Message-ID: <012001cf33e2$1db30250$591906f0$@gmail.com> Along those same lines, we've been using alias exec for the same thing for a while: Alias exec NTP 6500_NTP_V1.0.1 Alias exec bgp 6500_peer_V2.0.0 Thanks, Chuck -----Original Message----- From: Tim Durack [mailto:tdurack at gmail.com] Sent: Thursday, February 27, 2014 11:50 AM To: Ryan Shea Cc: nanog at nanog.org Subject: Re: Managing IOS Configuration Snippets On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea wrote: > A couple more thoughts, regarding > > Network => DB > > I completely agree that trying to use the network config itself as the > authority for what we intend to be on a device is not the right > long-term approach. There is still a problem with Network => DB that I > see. Assuming you have *many* devices, that may or may not be up at a > given time, or may be in various stages of turn-up / burn-in / decom > it is expected that a config change will not successfully make it to > all devices. There are other timing issues, like a config built for a > device being turned up, followed by a push of an update to all devices > that "succeeds", followed by the final turn-up of this device. Even if > you have a fancy config pushing engine, let's just take as a given > that you'll need to scrub through your rancid-git backups to determine what needs to be updated. > > Regarding the MD5 approach, let's also think that configlets could > have "no" commands in them. In the NTP example I had before, if we > wanted to remove an NTP server the configlet would need the "no" > version, but the rancid backup obviously would not have this. I'm not > trying to work a unit test assertion framework here either. Some > vendors have more robust commenting, and this can be quite convenient > for explicitly stating what was pushed to the device. What are you > using in your network... banner, snmp-location, hope, prayer? > We don't do this, but the only flexible commenting in IOS style configs is ACLs. You could have an ACL that contains remarks only, and include version information: ip access-list CFG-VER remark CFG-VER-NTP 1.0.3 remark CFG-VER-VTY 4.3.2 end You could break this into individual ACLs if you prefer: ip access-list CFG-VER-NTP remark CFG-VER-NTP 1.0.3 end ip access-list CFG-VER-VTY remark CFG-VER-VTY 4.3.2 end Seems ridiculous, but that is the sorry state of the network OS. -- Tim:> From erikm at buh.org Thu Feb 27 17:46:13 2014 From: erikm at buh.org (Erik Muller) Date: Thu, 27 Feb 2014 12:46:13 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530F7039.4050703@buh.org> Message-ID: <530F79E5.6030907@buh.org> On 2/27/14, 12:21 , Suresh Ramasubramanian wrote: > This has been around for several years now - > http://sourceforge.net/projects/cisco-conf-rep/ But that's just archiving, like rancid, right? Still doesn't have any correlation to the template-management side of things. While having the backups makes it easy to check for simple things ("do all my routers have the right syslog host set?"), OP's question is about tracking what versions of templates may have been applied to routers; if there's any complex logic (like, "are all active customer routes on this device included in the bcp38 acl on the upstream interface") or site-specific things, that can get a lot harder to audit without the metadata on how the configuration got there. -e From simon.knight at gmail.com Thu Feb 27 18:23:12 2014 From: simon.knight at gmail.com (Simon Knight) Date: Thu, 27 Feb 2014 10:23:12 -0800 Subject: Managing IOS Configuration Snippets In-Reply-To: <530F79E5.6030907@buh.org> References: <530F7039.4050703@buh.org> <530F79E5.6030907@buh.org> Message-ID: A lot of template management discussion focusses on using the network configs as the canonical model of the network. Storing the network model in the DB (whatever form that takes) is much more sane. There is the brownfields issue of populating that database and then building device state from there, but once that's done a lot of the problems go away. A solution like rancid/tail-f then simply becomes the mechanics to push your device state to the devices. Some good stuff here: https://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf --Simon On 27 February 2014 09:46, Erik Muller wrote: > On 2/27/14, 12:21 , Suresh Ramasubramanian wrote: >> >> This has been around for several years now - >> http://sourceforge.net/projects/cisco-conf-rep/ > > > But that's just archiving, like rancid, right? Still doesn't have any > correlation to the template-management side of things. While having the > backups makes it easy to check for simple things ("do all my routers have > the right syslog host set?"), OP's question is about tracking what versions > of templates may have been applied to routers; if there's any complex logic > (like, "are all active customer routes on this device included in the bcp38 > acl on the upstream interface") or site-specific things, that can get a lot > harder to audit without the metadata on how the configuration got there. > -e > > From ryanshea at google.com Thu Feb 27 18:39:08 2014 From: ryanshea at google.com (Ryan Shea) Date: Thu, 27 Feb 2014 13:39:08 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <530F7039.4050703@buh.org> References: <530F7039.4050703@buh.org> Message-ID: Very cool, thanks Erik. I can think of many ways to encode version metadata. Probably best to be somewhere in between overly verbose (full version $Id / date / author for every config chunk) and being unreadable (base64 encoded gzip of unique configlet identifiers and versions). Updating a banner feels a bit easier when you are pushing a full device-specific configuration from a templating system. Regardless of where it is stored, keeping the metadata in one of these fields (banner for example) means that checking the contents of the banner configlet now requires slightly more logic - which is fine. Chuck, interesting use of alias. Simon, completely agree that the network itself should not be the intent store. The real focus here is when your intent is in a DB/templating system thingy, how do you operationally ensure that intent matches reality. Again, with many devices going through upgrades, disabled/unreachable devices, new devices, pre-configured devices. The intent pusher is not blindly and constantly pushing to all devices, and it's likely not safe to do that. On Thu, Feb 27, 2014 at 12:04 PM, Erik Muller wrote: > On 2/26/14, 16:22 , Ryan Shea wrote: > >> Howdy network operator cognoscenti, >> >> I'd love to hear your creative and workable solutions for a way to track >> in-line the configuration revisions you have on your cisco-like devices. >> > ... > > >> Assume that this version encoding perfectly captures what is on the router >> and that no person is monkeying with the config... version 77 of the >> control plane filter is the same everywhere. >> > > At a previous job, our roll-your-own solution was a template based > system(*) generating full configs; all the version history for template > sections, per-router local tweaks, and generated results was kept in RCS, > and the actual last-configured version, plus any incremental changes, was > kept in the login banner. > So at login you'd see something like: > > blah blah authorized users blah blah > $Id: routername-confg,v 1.23 2013/08/20 03:07:16 username Exp > INCR: 1.2,1.3,1.4,1.5,1.6 > > and that version tracking made its way through to rancid for easy offline > auditing. This made it nice and easy to tell when and what had been > updated, though it still would take a couple steps to identify what exact > subsections had been changed over time (since the incremental version tags > were specific deltas in per-device configurations. You could probably do > it in a more global way too - git commit ids, maybe? - but you also don't > want to make the version string too wordy either). > > -e > > * based on ftp://ftp.cac.washington.edu/pub/config-generator/, but > substantially enhanced beyond the last public domain version. I know I'd > be really happy if the current version was ever open-sourced... > > From simon.knight at gmail.com Thu Feb 27 18:47:09 2014 From: simon.knight at gmail.com (Simon Knight) Date: Thu, 27 Feb 2014 10:47:09 -0800 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <530F7039.4050703@buh.org> Message-ID: On 27 February 2014 10:39, Ryan Shea wrote: > Very cool, thanks Erik. I can think of many ways to encode version > metadata. Probably best to be somewhere in between overly verbose (full > version $Id / date / author for every config chunk) and being unreadable > (base64 encoded gzip of unique configlet identifiers and versions). > Updating a banner feels a bit easier when you are pushing a full > device-specific configuration from a templating system. Regardless of where > it is stored, keeping the metadata in one of these fields (banner for > example) means that checking the contents of the banner configlet now > requires slightly more logic - which is fine. > > Chuck, interesting use of alias. > > Simon, completely agree that the network itself should not be the intent > store. The real focus here is when your intent is in a DB/templating system > thingy, how do you operationally ensure that intent matches reality. Again, > with many devices going through upgrades, disabled/unreachable devices, new > devices, pre-configured devices. The intent pusher is not blindly and > constantly pushing to all devices, and it's likely not safe to do that. Absolutely. Expect/SNMP/config scraping is a solution here. It's tedious and boring to write the hooks, but it's not impossible. A solution like tail-f is a much better solution here. My personal preference would be to just push/pull JSON off the devices. I think there are two separate components here (which are often conflated): the mechanics to push/pull from devices into a data structure, and the network database to work with those data structures. There's a place for both device level models and network level models. --Simon > > > On Thu, Feb 27, 2014 at 12:04 PM, Erik Muller wrote: > >> On 2/26/14, 16:22 , Ryan Shea wrote: >> >>> Howdy network operator cognoscenti, >>> >>> I'd love to hear your creative and workable solutions for a way to track >>> in-line the configuration revisions you have on your cisco-like devices. >>> >> ... >> >> >>> Assume that this version encoding perfectly captures what is on the router >>> and that no person is monkeying with the config... version 77 of the >>> control plane filter is the same everywhere. >>> >> >> At a previous job, our roll-your-own solution was a template based >> system(*) generating full configs; all the version history for template >> sections, per-router local tweaks, and generated results was kept in RCS, >> and the actual last-configured version, plus any incremental changes, was >> kept in the login banner. >> So at login you'd see something like: >> >> blah blah authorized users blah blah >> $Id: routername-confg,v 1.23 2013/08/20 03:07:16 username Exp >> INCR: 1.2,1.3,1.4,1.5,1.6 >> >> and that version tracking made its way through to rancid for easy offline >> auditing. This made it nice and easy to tell when and what had been >> updated, though it still would take a couple steps to identify what exact >> subsections had been changed over time (since the incremental version tags >> were specific deltas in per-device configurations. You could probably do >> it in a more global way too - git commit ids, maybe? - but you also don't >> want to make the version string too wordy either). >> >> -e >> >> * based on ftp://ftp.cac.washington.edu/pub/config-generator/, but >> substantially enhanced beyond the last public domain version. I know I'd >> be really happy if the current version was ever open-sourced... >> >> From jabley at hopcount.ca Thu Feb 27 20:52:06 2014 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 27 Feb 2014 15:52:06 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <530F79E5.6030907@buh.org> References: <530F7039.4050703@buh.org> <530F79E5.6030907@buh.org> Message-ID: <7CB56FA9-54F1-460B-AA1B-952A176BD395@hopcount.ca> On 27 Feb 2014, at 12:46, Erik Muller wrote: > On 2/27/14, 12:21 , Suresh Ramasubramanian wrote: >> This has been around for several years now - >> http://sourceforge.net/projects/cisco-conf-rep/ > > But that's just archiving, like rancid, right? This is not any kind of sensible answer to the original question, but the general approach ?give ops people a shell on a box with a rancid repository, encourage them to write scripts that do stuff? has the potential to cause all kinds of good things to happen faster than the time taken to organise a conference call to discuss requirements gathering for a ?production? system. Examples, as ever: http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf ftp://ftp.isc.org/isc/toolmakers/ (It?s not pretty. But it?s not supposed to be pretty.) Joe From erikm at buh.org Thu Feb 27 21:05:47 2014 From: erikm at buh.org (Erik Muller) Date: Thu, 27 Feb 2014 16:05:47 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <7CB56FA9-54F1-460B-AA1B-952A176BD395@hopcount.ca> References: <530F7039.4050703@buh.org> <530F79E5.6030907@buh.org> <7CB56FA9-54F1-460B-AA1B-952A176BD395@hopcount.ca> Message-ID: <530FA8AB.6090905@buh.org> On 2/27/14, 15:52 , Joe Abley wrote: > This is not any kind of sensible answer to the original question, but > the general approach ?give ops people a shell on a box with a rancid > repository, encourage them to write scripts that do stuff? has the > potential to cause all kinds of good things to happen faster than the > time taken to organise a conference call to discuss requirements > gathering for a ?production? system. +1000. And that applies equally to the backend. I have yet to meet a fancy, integrated, database-driven configuration management system that can beat a bunch of flat files and a few perl scripts. Hackability of a system can be a definite virtue here. -e From richard at pedantictheory.com Thu Feb 27 21:33:40 2014 From: richard at pedantictheory.com (Richard Porter) Date: Thu, 27 Feb 2014 14:33:40 -0700 Subject: Hat - bcp38.info - Storm Center Diary Message-ID: <92C7A185-087D-45E9-BAC6-D987BA7D749D@pedantictheory.com> Hat, A reader suggested I reach out to you, he thought you might like a simple graphic I put together on the Storm Center Diary post. Talked about BCP38 today. Email me off list and I will send it. ~Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From simon.knight at gmail.com Thu Feb 27 21:45:38 2014 From: simon.knight at gmail.com (Simon Knight) Date: Thu, 27 Feb 2014 13:45:38 -0800 Subject: Managing IOS Configuration Snippets In-Reply-To: <530FA8AB.6090905@buh.org> References: <530F7039.4050703@buh.org> <530F79E5.6030907@buh.org> <7CB56FA9-54F1-460B-AA1B-952A176BD395@hopcount.ca> <530FA8AB.6090905@buh.org> Message-ID: Definitely. Depends what form the database takes - I don't think SQL is the right answer here. Sticking with flat files and perl scripts as much as possible is good guidance. I'm biased, but I'd go with Python: http://www.youtube.com/watch?v=EGK5jjyUBCQ --Simon On 27 February 2014 13:05, Erik Muller wrote: > On 2/27/14, 15:52 , Joe Abley wrote: >> >> This is not any kind of sensible answer to the original question, but >> the general approach "give ops people a shell on a box with a rancid >> repository, encourage them to write scripts that do stuff" has the >> potential to cause all kinds of good things to happen faster than the >> time taken to organise a conference call to discuss requirements >> gathering for a "production" system. > > > +1000. And that applies equally to the backend. I have yet to meet a > fancy, integrated, database-driven configuration management system that can > beat a bunch of flat files and a few perl scripts. Hackability of a system > can be a definite virtue here. > -e > > From no.spam at comcast.net Fri Feb 28 01:38:42 2014 From: no.spam at comcast.net (Keegan Holley) Date: Thu, 27 Feb 2014 20:38:42 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: Message-ID: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Putting aside the fact that snippets aren?t a good way to conceptualize deployed router code, my gut still tells me to question the question here. The first is does this stuff change often enough to warrant a fancy versioning solution? I have yet to see NTP deployed in a different way than when I first learned to configure it. Next, when it does change how often is it not rolled out to every router. If NTP or CPP or SNMP or some other administrative option were configured differently across my network I would want to audit it and fix not version control. What if some of the configs don?t match the defined versions? It may be better to create standard templates and version them in SVN or GIT and then use config backups to track which devices have the standard configs. There are some for pay tools that can search for certain statements on various boxes and either alert or remediate when differences are found. On Feb 26, 2014, at 4:22 PM, Ryan Shea wrote: > Howdy network operator cognoscenti, > > I'd love to hear your creative and workable solutions for a way to track > in-line the configuration revisions you have on your cisco-like devices. > Let me clearify/frame: > > You have a set of tested/approved configurations for your routers which use > IOS style configuration. These configurations of course are always refined > and updated. You break these pieces of configuration into logical sections, > for example a configuration file for NTP configuration, a file for control > plane filter and store these in some revision control system. Put aside for > the moment whether this is a reasonable way to comprehend deployed > configurations. What methods do some of you use to know which version of a > configuration you have deployed to a given router for auditing and update > purposes? Remarks are a convenient way to do this for ACLs - but I don't > have similar mechanics for top level configurations. About a decade ago I > thought I'd be super clever and encode versioning information into the snmp > location - but that is just awful and there is a much better way everyone > is using, right? Flexible commenting on other vendors/platforms make this a > bit easier. > > Assume that this version encoding perfectly captures what is on the router > and that no person is monkeying with the config... version 77 of the > control plane filter is the same everywhere. From no.spam at comcast.net Fri Feb 28 01:42:44 2014 From: no.spam at comcast.net (Keegan Holley) Date: Thu, 27 Feb 2014 20:42:44 -0500 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> Message-ID: <4FD401C2-C03F-4B0D-B2EF-DAF52D84EAB0@comcast.net> On Feb 26, 2014, at 12:44 PM, Brandon Galbraith wrote: > On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley wrote: > > More politely stated, it?s not the responsibility of the operator to decide what belongs on the network and what doesn?t. Users can run any services that?s not illegal or even reuse ports for other applications. That being said commonly exploited ports (TCP 25 for example) are often blocked. This is usually done to block or protect an application though not to single out a particular port number. > > Don't most residential ISPs already block port 25 outbound? http://www.postcastserver.com/help/Port_25_Blocking.aspx > > Blocking chargen at the edge doesn't seem to be outside of the realm of possibilities. As I said, SMTP is blocked because it?s the default port for a commonly run and often misconfigured application. Blocking the chargen port is definitely reasonable, but it?s not a popular application. Most people use the port as an clever non-default port for some other service like ssh. From no.spam at comcast.net Fri Feb 28 01:57:14 2014 From: no.spam at comcast.net (Keegan Holley) Date: Thu, 27 Feb 2014 20:57:14 -0500 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> Message-ID: <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> It depends on how many customers you have and what sort of contract you have with them if any. A significant amount of attack traffic comes from residential networks where a ?one-size-fits-all? policy is definitely best. On Feb 26, 2014, at 4:01 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brandon Galbraith" > >> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley >> wrote: >>> More politely stated, it?s not the responsibility of the operator to >>> decide what belongs on the network and what doesn?t. Users can run any >>> services that?s not illegal or even reuse ports for other >>> applications. > >> Blocking chargen at the edge doesn't seem to be outside of the realm >> of possibilities. > > All of these conversations are variants of "how easy is it to set up a > default ACL for loops, and then manage exceptions to it?". > > Assuming your gear permits it, I don't personally see all that much > Bad Actorliness in setting a relatively tight bidirectional ACL for > Random Edge Customers, and opening up -- either specific ports, or > just "to a less-/un-filtered ACL" on specific request. > > The question is -- as it is with BCP38 -- *can the edge gear handle it*? > > And if not: why not? (Protip: because buyers of that gear aren't > agitating for it) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > From trissypissy at gmail.com Thu Feb 27 06:44:50 2014 From: trissypissy at gmail.com (Tristan Lear) Date: Thu, 27 Feb 2014 01:44:50 -0500 Subject: Verizon FIOS IPv6? Message-ID: My strategy, should I remember it tomorrow: We have a business-class FIOS?connection where I work and a static IP?as well. At least three people who work here have FIOS?at home. I've read rumors about business class customers who really work their phone sex getting native ipv6, and I also heard somethin about static ip's. So I'll try that, and also mention that "we're transitioning our employees who remote in from home to FIOS but we'd like ipv6?for ...?VPN purposes, NAT traversal, etc ..." I mean, that should get them a little wet right? I have a bit of a hairbrained theory that the reason ISP's?have stagnated on ipv6 has to do with relationship between capitalism and scarcity. Having a limited quantity of anything makes it more valuable. Why wouldn't that apply to IP's? From aidan at aodhandigital.com Thu Feb 27 16:58:58 2014 From: aidan at aodhandigital.com (Aidan Scheller) Date: Thu, 27 Feb 2014 10:58:58 -0600 Subject: congestion between Cogent and CenturyLink Message-ID: Hello, We send periodic 10-15Mbps bursts of traffic to a business partner and it appears to transition from Cogent to Century Link in Atlanta. During the day performance is normal and latency appears acceptable on a trace route. 12 ms 13 ms 12 ms te0-6-1-7.rcr21.msp01.atlas.cogentco.com [38.88.188.41] 26 ms 26 ms 27 ms be2410.ccr22.ord01.atlas.cogentco.com [154.54.7.229] 43 ms 44 ms 44 ms be2099.ccr22.atl01.atlas.cogentco.com [154.54.28.74] 44 ms 44 ms 44 ms be2051.ccr21.atl02.atlas.cogentco.com [154.54.0.162] 43 ms 42 ms 43 ms qwest.atl02.atlas.cogentco.com [154.54.13.30] 49 ms 49 ms 50 ms min-edge-10.inet.qwest.net [205.171.128.154] But after hours latency spikes and throughput drops to less than 1Mbps. te8-3.ccr01.msp01.atlas.cogentco.com (38.88.188.41) 4.603 ms te0-0-0-19.mpd22.ord01.atlas.cogentco.com (154.54.1.230) 17.838 ms be2099.ccr22.atl01.atlas.cogentco.com (154.54.28.74) 33.156 ms be2051.ccr21.atl02.atlas.cogentco.com (154.54.0.162) 36.449 ms qwest.atl02.atlas.cogentco.com (154.54.13.30) 89.583 ms min-edge-10.inet.qwest.net (205.171.128.150) 89.806 ms Century Link stated that Cogent is oversubscribing the link, and that they've requested Cogent resolve the problem, but that action has yet to be taken. I've tried reaching out to Cogent but as we're not a direct customer they wouldn't provide assistance. Has anyone else seen similar issues? Thanks, Aidan From dhubbard at dino.hostasaurus.com Fri Feb 28 02:13:19 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 27 Feb 2014 21:13:19 -0500 Subject: Verizon FIOS IPv6? References: Message-ID: Good luck. We've been bitching at our sales rep for years, as we've added circuits, and haven't gotten even empty promises; just the same endless Verizon BS about "it's being tested in select markets" although no one has ever been able to prove that to be the case. You definitely get static IP's on business connections; that's just a matter of how much you pay and how many you need. David -----Original Message----- From: Tristan Lear [mailto:trissypissy at gmail.com] Sent: Thursday, February 27, 2014 1:45 AM To: nanog at nanog.org Subject: Verizon FIOS IPv6? My strategy, should I remember it tomorrow: We have a business-class FIOS?connection where I work and a static IP?as well. At least three people who work here have FIOS?at home. I've read rumors about business class customers who really work their phone sex getting native ipv6, and I also heard somethin about static ip's. So I'll try that, and also mention that "we're transitioning our employees who remote in from home to FIOS but we'd like ipv6?for ...?VPN purposes, NAT traversal, etc ..." I mean, that should get them a little wet right? I have a bit of a hairbrained theory that the reason ISP's?have stagnated on ipv6 has to do with relationship between capitalism and scarcity. Having a limited quantity of anything makes it more valuable. Why wouldn't that apply to IP's? From sfrost at snowman.net Fri Feb 28 02:18:08 2014 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 27 Feb 2014 21:18:08 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: Message-ID: <20140228021808.GU2921@tamriel.snowman.net> I echo the 'good luck' and ditto on the experience. There's a lot of people anxious to get IPv6 on FIOS, but there seems to be precious little movement over there. * David Hubbard (dhubbard at dino.hostasaurus.com) wrote: > Good luck. We've been bitching at our sales rep for years, as we've added circuits, and haven't gotten even empty promises; just the same endless Verizon BS about "it's being tested in select markets" although no one has ever been able to prove that to be the case. You definitely get static IP's on business connections; that's just a matter of how much you pay and how many you need. > > David > > -----Original Message----- > From: Tristan Lear [mailto:trissypissy at gmail.com] > Sent: Thursday, February 27, 2014 1:45 AM > To: nanog at nanog.org > Subject: Verizon FIOS IPv6? > > My strategy, should I remember it tomorrow: > > We have a business-class FIOS?connection where I work and a static IP?as well. At least three people who work here have FIOS?at home. I've read rumors about business class customers who really work their phone sex getting native ipv6, and I also heard somethin about static ip's. So I'll try that, and also mention that "we're transitioning our employees who remote in from home to FIOS but we'd like ipv6?for ...?VPN purposes, NAT traversal, etc ..." I mean, that should get them a little wet right? > > I have a bit of a hairbrained theory that the reason ISP's?have stagnated on ipv6 has to do with relationship between capitalism and scarcity. Having a limited quantity of anything makes it more valuable. Why wouldn't that apply to IP's? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From seitz at bsd-unix.net Fri Feb 28 02:24:00 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 27 Feb 2014 21:24:00 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <20140228021808.GU2921@tamriel.snowman.net> References: <20140228021808.GU2921@tamriel.snowman.net> Message-ID: <20140228022400.GA76314@bsd-unix.net> On Thu, Feb 27, 2014 at 09:18:08PM -0500, Stephen Frost wrote: > I echo the 'good luck' and ditto on the experience. > > There's a lot of people anxious to get IPv6 on FIOS, but there seems to > be precious little movement over there. > > * David Hubbard (dhubbard at dino.hostasaurus.com) wrote: > > Good luck. We've been bitching at our sales rep for years, as we've added circuits, and haven't gotten even empty promises; just the same endless Verizon BS about "it's being tested in select markets" although no one has ever been able to prove that to be the case. You definitely get static IP's on business connections; that's just a matter of how much you pay and how many you need. > > > > David Another ditto :) I think they are Defnitely milking their highway robbery IPV4 allocation costs. Confidence is low for IPV6 from FIOS anytime soon. -- Bryan G. Seitz From morrowc.lists at gmail.com Fri Feb 28 02:41:44 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Feb 2014 21:41:44 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <20140228021808.GU2921@tamriel.snowman.net> References: <20140228021808.GU2921@tamriel.snowman.net> Message-ID: On Thu, Feb 27, 2014 at 9:18 PM, Stephen Frost wrote: > I echo the 'good luck' and ditto on the experience. > > There's a lot of people anxious to get IPv6 on FIOS, but there seems to > be precious little movement over there. > it really is just an embarrassment :( perhaps shame will work to motivate them instead? > * David Hubbard (dhubbard at dino.hostasaurus.com) wrote: >> Good luck. We've been bitching at our sales rep for years, as we've added circuits, and haven't gotten even empty promises; just the same endless Verizon BS about "it's being tested in select markets" although no one has ever been able to prove that to be the case. You definitely get static IP's on business connections; that's just a matter of how much you pay and how many you need. >> >> David >> >> -----Original Message----- >> From: Tristan Lear [mailto:trissypissy at gmail.com] >> Sent: Thursday, February 27, 2014 1:45 AM >> To: nanog at nanog.org >> Subject: Verizon FIOS IPv6? >> >> My strategy, should I remember it tomorrow: >> >> We have a business-class FIOS connection where I work and a static IP as well. At least three people who work here have FIOS at home. I've read rumors about business class customers who really work their phone sex getting native ipv6, and I also heard somethin about static ip's. So I'll try that, and also mention that "we're transitioning our employees who remote in from home to FIOS but we'd like ipv6 for ... VPN purposes, NAT traversal, etc ..." I mean, that should get them a little wet right? >> >> I have a bit of a hairbrained theory that the reason ISP's have stagnated on ipv6 has to do with relationship between capitalism and scarcity. Having a limited quantity of anything makes it more valuable. Why wouldn't that apply to IP's? >> >> From sfrost at snowman.net Fri Feb 28 02:48:50 2014 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 27 Feb 2014 21:48:50 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <20140228021808.GU2921@tamriel.snowman.net> Message-ID: <20140228024850.GX2921@tamriel.snowman.net> * Christopher Morrow (morrowc.lists at gmail.com) wrote: > On Thu, Feb 27, 2014 at 9:18 PM, Stephen Frost wrote: > > There's a lot of people anxious to get IPv6 on FIOS, but there seems to > > be precious little movement over there. > > it really is just an embarrassment :( Oh, I agree, and the old UUNET folks (whose side of that house has had this done for, uh, forever...) should really take ownership and scream bloody murder at the FIOS people to either get their $h1t together or get out of the way. > perhaps shame will work to motivate them instead? It hasn't worked thus far, though I admit, I've been tempted more than once to call them and threaten that I'm going to switch to Comcast, if it wasn't such a laughable idea. :/ Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From ops.lists at gmail.com Fri Feb 28 02:55:56 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 28 Feb 2014 08:25:56 +0530 Subject: congestion between Cogent and CenturyLink In-Reply-To: References: Message-ID: With cogent? Now you will be asking us if the Pope is really Catholic :) On 28-Feb-2014 7:43 AM, "Aidan Scheller" wrote: > Hello, > > > > We send periodic 10-15Mbps bursts of traffic to a business partner and it > appears to transition from Cogent to Century Link in Atlanta. During the > day performance is normal and latency appears acceptable on a trace route. > > > > 12 ms 13 ms 12 ms te0-6-1-7.rcr21.msp01.atlas.cogentco.com [38.88.188.41] > > 26 ms 26 ms 27 ms be2410.ccr22.ord01.atlas.cogentco.com [154.54.7.229] > > 43 ms 44 ms 44 ms be2099.ccr22.atl01.atlas.cogentco.com [154.54.28.74] > > 44 ms 44 ms 44 ms be2051.ccr21.atl02.atlas.cogentco.com [154.54.0.162] > > 43 ms 42 ms 43 ms qwest.atl02.atlas.cogentco.com [154.54.13.30] > > 49 ms 49 ms 50 ms min-edge-10.inet.qwest.net [205.171.128.154] > > > > But after hours latency spikes and throughput drops to less than 1Mbps. > > > > te8-3.ccr01.msp01.atlas.cogentco.com (38.88.188.41) 4.603 ms > > te0-0-0-19.mpd22.ord01.atlas.cogentco.com (154.54.1.230) 17.838 ms > > be2099.ccr22.atl01.atlas.cogentco.com (154.54.28.74) 33.156 ms > > be2051.ccr21.atl02.atlas.cogentco.com (154.54.0.162) 36.449 ms > > qwest.atl02.atlas.cogentco.com (154.54.13.30) 89.583 ms > > min-edge-10.inet.qwest.net (205.171.128.150) 89.806 ms > > > > Century Link stated that Cogent is oversubscribing the link, and that > they've requested Cogent resolve the problem, but that action has yet to be > taken. I've tried reaching out to Cogent but as we're not a direct > customer they wouldn't provide assistance. > > > > Has anyone else seen similar issues? > > > > Thanks, > > > > Aidan > From morrowc.lists at gmail.com Fri Feb 28 02:57:15 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Feb 2014 21:57:15 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <20140228024850.GX2921@tamriel.snowman.net> References: <20140228021808.GU2921@tamriel.snowman.net> <20140228024850.GX2921@tamriel.snowman.net> Message-ID: On Thu, Feb 27, 2014 at 9:48 PM, Stephen Frost wrote: > * Christopher Morrow (morrowc.lists at gmail.com) wrote: >> On Thu, Feb 27, 2014 at 9:18 PM, Stephen Frost wrote: >> > There's a lot of people anxious to get IPv6 on FIOS, but there seems to >> > be precious little movement over there. >> >> it really is just an embarrassment :( > > Oh, I agree, and the old UUNET folks (whose side of that house has had > this done for, uh, forever...) should really take ownership and scream > bloody murder at the FIOS people to either get their $h1t together or > get out of the way. most of them did this, like 5+ yrs ago :( when they stopped being listened to, they left. (most of them) > >> perhaps shame will work to motivate them instead? > > It hasn't worked thus far, though I admit, I've been tempted more than > once to call them and threaten that I'm going to switch to Comcast, if > it wasn't such a laughable idea. :/ > > Thanks, > > Stephen From morrowc.lists at gmail.com Fri Feb 28 03:03:37 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Feb 2014 22:03:37 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley wrote: > Putting aside the fact that snippets aren't a good way to conceptualize deployed router code, my gut still tells me to question the question here. The first is does this stuff change often enough to warrant a fancy versioning solution? I have yet to see NTP deployed in a different way than when I first learned to configure it. Next, when it does change how often is it not rolled out to every router. If NTP or CPP or SNMP or some other administrative option were configured differently across my sure, so you're saying that a large bit (maybe) of the router config is 'one size fits all' and 'never changes' where 'never' is really 'very infrequently'. sure, agreed... but there are parts of the config that do change more frequently (depending on the network perhaps)... how do you go about seeing which version / setup is deployed EXCEPT by building a home-grown 'config parser' and seeing that 'what is deployed matches mostly what I have in my config store for this router/class-of-router/network' ? It's a shame that vendors of network equipment don't have to manage large networks of their own equipment under constrained opex environments (no fair comparing contracted work where you bill for time + materials, that's the wrong incentive set)... I bet that'd get them to fix stuff up right quick. network I would want to audit it and fix not version control. What if some of the configs don't match the defined versions? It may be better to create standard templates and version them in SVN or GIT and then use config backups to track which devices have the standard configs. There are some for pay tools that can search for certain statements on various boxes and either alert or remediate when differences are found. > > > On Feb 26, 2014, at 4:22 PM, Ryan Shea wrote: > >> Howdy network operator cognoscenti, >> >> I'd love to hear your creative and workable solutions for a way to track >> in-line the configuration revisions you have on your cisco-like devices. >> Let me clearify/frame: >> >> You have a set of tested/approved configurations for your routers which use >> IOS style configuration. These configurations of course are always refined >> and updated. You break these pieces of configuration into logical sections, >> for example a configuration file for NTP configuration, a file for control >> plane filter and store these in some revision control system. Put aside for >> the moment whether this is a reasonable way to comprehend deployed >> configurations. What methods do some of you use to know which version of a >> configuration you have deployed to a given router for auditing and update >> purposes? Remarks are a convenient way to do this for ACLs - but I don't >> have similar mechanics for top level configurations. About a decade ago I >> thought I'd be super clever and encode versioning information into the snmp >> location - but that is just awful and there is a much better way everyone >> is using, right? Flexible commenting on other vendors/platforms make this a >> bit easier. >> >> Assume that this version encoding perfectly captures what is on the router >> and that no person is monkeying with the config... version 77 of the >> control plane filter is the same everywhere. > > From contact at winterei.se Fri Feb 28 03:04:34 2014 From: contact at winterei.se (Paul S.) Date: Fri, 28 Feb 2014 12:04:34 +0900 Subject: congestion between Cogent and CenturyLink In-Reply-To: References: Message-ID: <530FFCC2.6070004@winterei.se> +1, which semi-large eyeball does Cogent NOT have capacity problems to? On 2/28/2014 ?? 11:55, Suresh Ramasubramanian wrote: > With cogent? Now you will be asking us if the Pope is really Catholic :) > On 28-Feb-2014 7:43 AM, "Aidan Scheller" wrote: > >> Hello, >> >> >> >> We send periodic 10-15Mbps bursts of traffic to a business partner and it >> appears to transition from Cogent to Century Link in Atlanta. During the >> day performance is normal and latency appears acceptable on a trace route. >> >> >> >> 12 ms 13 ms 12 ms te0-6-1-7.rcr21.msp01.atlas.cogentco.com [38.88.188.41] >> >> 26 ms 26 ms 27 ms be2410.ccr22.ord01.atlas.cogentco.com [154.54.7.229] >> >> 43 ms 44 ms 44 ms be2099.ccr22.atl01.atlas.cogentco.com [154.54.28.74] >> >> 44 ms 44 ms 44 ms be2051.ccr21.atl02.atlas.cogentco.com [154.54.0.162] >> >> 43 ms 42 ms 43 ms qwest.atl02.atlas.cogentco.com [154.54.13.30] >> >> 49 ms 49 ms 50 ms min-edge-10.inet.qwest.net [205.171.128.154] >> >> >> >> But after hours latency spikes and throughput drops to less than 1Mbps. >> >> >> >> te8-3.ccr01.msp01.atlas.cogentco.com (38.88.188.41) 4.603 ms >> >> te0-0-0-19.mpd22.ord01.atlas.cogentco.com (154.54.1.230) 17.838 ms >> >> be2099.ccr22.atl01.atlas.cogentco.com (154.54.28.74) 33.156 ms >> >> be2051.ccr21.atl02.atlas.cogentco.com (154.54.0.162) 36.449 ms >> >> qwest.atl02.atlas.cogentco.com (154.54.13.30) 89.583 ms >> >> min-edge-10.inet.qwest.net (205.171.128.150) 89.806 ms >> >> >> >> Century Link stated that Cogent is oversubscribing the link, and that >> they've requested Cogent resolve the problem, but that action has yet to be >> taken. I've tried reaching out to Cogent but as we're not a direct >> customer they wouldn't provide assistance. >> >> >> >> Has anyone else seen similar issues? >> >> >> >> Thanks, >> >> >> >> Aidan >> From sfrost at snowman.net Fri Feb 28 03:21:30 2014 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 27 Feb 2014 22:21:30 -0500 Subject: congestion between Cogent and CenturyLink In-Reply-To: <530FFCC2.6070004@winterei.se> References: <530FFCC2.6070004@winterei.se> Message-ID: <20140228032130.GZ2921@tamriel.snowman.net> * Paul S. (contact at winterei.se) wrote: > +1, which semi-large eyeball does Cogent NOT have capacity problems to? Soon, Comcast... Given what's going on w/ them and Netflix. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jason at unlimitednet.us Fri Feb 28 03:22:50 2014 From: jason at unlimitednet.us (Jason Canady) Date: Thu, 27 Feb 2014 22:22:50 -0500 Subject: congestion between Cogent and CenturyLink In-Reply-To: <20140228032130.GZ2921@tamriel.snowman.net> References: <530FFCC2.6070004@winterei.se> <20140228032130.GZ2921@tamriel.snowman.net> Message-ID: I'm already seeing a huge improvement to Comcast after Netflix moved a lot of traffic off of the ports. On Feb 27, 2014, at 22:21, Stephen Frost wrote: > * Paul S. (contact at winterei.se) wrote: >> +1, which semi-large eyeball does Cogent NOT have capacity problems to? > > Soon, Comcast... Given what's going on w/ them and Netflix. > > Thanks, > > Stephen From edwardroels at gmail.com Fri Feb 28 03:33:32 2014 From: edwardroels at gmail.com (Edward Roels) Date: Thu, 27 Feb 2014 22:33:32 -0500 Subject: congestion between Cogent and CenturyLink In-Reply-To: References: <530FFCC2.6070004@winterei.se> <20140228032130.GZ2921@tamriel.snowman.net> Message-ID: I saw the same effect after the Netflix peering started. http://imgur.com/a/aVFAS On Thu, Feb 27, 2014 at 10:22 PM, Jason Canady wrote: > I'm already seeing a huge improvement to Comcast after Netflix moved a lot > of traffic off of the ports. > > > On Feb 27, 2014, at 22:21, Stephen Frost wrote: > > > * Paul S. (contact at winterei.se) wrote: > >> +1, which semi-large eyeball does Cogent NOT have capacity problems to? > > > > Soon, Comcast... Given what's going on w/ them and Netflix. > > > > Thanks, > > > > Stephen > > From jra at baylink.com Fri Feb 28 03:57:13 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Feb 2014 22:57:13 -0500 (EST) Subject: Verizon FIOS IPv6? In-Reply-To: Message-ID: <26465525.10348.1393559833892.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Thu, Feb 27, 2014 at 9:48 PM, Stephen Frost > wrote: > > * Christopher Morrow (morrowc.lists at gmail.com) wrote: > >> On Thu, Feb 27, 2014 at 9:18 PM, Stephen Frost > >> wrote: > >> > There's a lot of people anxious to get IPv6 on FIOS, but there > >> > seems to be precious little movement over there. > >> > >> it really is just an embarrassment :( > > > > Oh, I agree, and the old UUNET folks (whose side of that house has had > > this done for, uh, forever...) should really take ownership and scream > > bloody murder at the FIOS people to either get their $h1t together > > or get out of the way. > > most of them did this, like 5+ yrs ago :( > when they stopped being listened to, they left. (most of them) > >> perhaps shame will work to motivate them instead? > > > > It hasn't worked thus far, though I admit, I've been tempted more than > > once to call them and threaten that I'm going to switch to Comcast, if > > it wasn't such a laughable idea. :/ Well, for the record, I don't expect anything at all out of Vzn, since they got it made illegal for munis to own fiber in all or part of 19 states, at least in large part on the basis of promises that they wouldn't cherry pick in their FiOS rollouts... and then went and did just that; it's public record they did their last deployment in 2010, and they have no plans to do any more. Unless, of couse, some muni or Google moves into somewhere to roll out; *then* they'll be right there on your doorstep applying for trenching permits. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From streiner at cluebyfour.org Fri Feb 28 00:54:07 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 27 Feb 2014 19:54:07 -0500 (EST) Subject: Verizon FIOS IPv6? In-Reply-To: <20140228022400.GA76314@bsd-unix.net> References: <20140228021808.GU2921@tamriel.snowman.net> <20140228022400.GA76314@bsd-unix.net> Message-ID: On Thu, 27 Feb 2014, Bryan Seitz wrote: > On Thu, Feb 27, 2014 at 09:18:08PM -0500, Stephen Frost wrote: >> I echo the 'good luck' and ditto on the experience. >> >> There's a lot of people anxious to get IPv6 on FIOS, but there seems to >> be precious little movement over there. I've been fighting this battle for as long as I've had FIOS (about a year and a half), with no end in sight. Front-line reps don't know the situation, and I don't fault them for that. Getting a hold of anyone who comment with anything approaching authority has been impossible. In the meantime, I will continue using my tunnel through HE, which works great (kudos to HE). jms From streiner at cluebyfour.org Fri Feb 28 01:03:35 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 27 Feb 2014 20:03:35 -0500 (EST) Subject: Verizon FIOS IPv6? In-Reply-To: References: Message-ID: On Thu, 27 Feb 2014, Tristan Lear wrote: > We have a business-class FIOS?connection where I work and a static > IP?as well. At least three people who work here have FIOS?at home. > I've read rumors about business class customers who really work their > phone sex getting native ipv6, and I also heard somethin about static > ip's. So I'll try that, and also mention that "we're transitioning our > employees who remote in from home to FIOS but we'd like ipv6?for > ...?VPN purposes, NAT traversal, etc ..." I mean, that should get them > a little wet right? Not likely. Verizon is a very expensive date, so you *really* have to open the wallet to make that kind of impression, and by that point, you're working with VZ Enterprise, which is what used to be UUNET, where v6 is easy to get, so the point ends up being moot. > I have a bit of a hairbrained theory that the reason ISP's?have > stagnated on ipv6 has to do with relationship between capitalism and > scarcity. Having a limited quantity of anything makes it more valuable. > Why wouldn't that apply to IP's? I doubt it's anything quite so nefarious, though VZ trying to figure out how to monetize their IPv6 rollout is certainly a possibility. I've heard all sorts of BS answers as to why there is no v6 for FIOS, such as: 1. "We're having problems getting it to work on our set-top boxes." So go dual-stack and let the set-top boxes stay v4 until the problem gets worked out. VZ has already stated that dual-stack is the way thry're going to do it. 2. "We have plenty of IPv4 space." Perhaps today, yes, but that misses the point entirely. jms From rps at maine.edu Fri Feb 28 14:02:03 2014 From: rps at maine.edu (Ray Soucy) Date: Fri, 28 Feb 2014 09:02:03 -0500 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> Message-ID: I'm wondering how many operators don't have systems in place to quickly and efficiently filter problem host systems. I see a lot of talk of ACL usage, but not much about uRPF and black hole filtering. There are a few white papers that are worth a read: http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf http://www.cisco.com/web/about/security/intelligence/urpf.pdf If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. This prevents you from having to maintain ACLs or even give out access to routers. Instead, you can use a small router or daemon that disables hosts by advertising them as a route (for example, we just use a pair of small ISR 1841 routers for this); this in turn can be tied into IPS or a web UI allowing your NOC to disable a problem host at the first hop and prevent its traffic from propagating throughout the network without having to know the overall architecture of the network or determine the best place to apply an ACL. I've seen a lot of talk on trying to filter specific protocols, or rate-limit, etc. but I really feel that isn't the appropriate action to take. I think disabling a system that is a problem and notifying its maintainer that they need to correct the issue is much more sustainable. There are also limitations on how much can be done through the use of ACLs. uRPF and black hole routing scale much better, especially in response to a denial of service attack. When the NTP problems first started popping up, we saw incoming NTP of several Gb, without the ability to quickly identify and filter this traffic a lot of our users would have been dead in the water because the firewalls they use just can't handle that much traffic; our routers, on the other hand, have no problem throwing those packets out. I only comment on this because one of the comments made to me was "Can't we just use a firewall to block it?". It took me over an hour to explain that the firewalls in use didn't have the capacity to handle this level of traffic -- and when I tried to discuss hardware vs. software filtering, I got a deer-in-the-headlights look. :-) On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley wrote: > It depends on how many customers you have and what sort of contract you have with them if any. A significant amount of attack traffic comes from residential networks where a "one-size-fits-all" policy is definitely best. > > On Feb 26, 2014, at 4:01 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Brandon Galbraith" >> >>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley >>> wrote: >>>> More politely stated, it's not the responsibility of the operator to >>>> decide what belongs on the network and what doesn't. Users can run any >>>> services that's not illegal or even reuse ports for other >>>> applications. >> >>> Blocking chargen at the edge doesn't seem to be outside of the realm >>> of possibilities. >> >> All of these conversations are variants of "how easy is it to set up a >> default ACL for loops, and then manage exceptions to it?". >> >> Assuming your gear permits it, I don't personally see all that much >> Bad Actorliness in setting a relatively tight bidirectional ACL for >> Random Edge Customers, and opening up -- either specific ports, or >> just "to a less-/un-filtered ACL" on specific request. >> >> The question is -- as it is with BCP38 -- *can the edge gear handle it*? >> >> And if not: why not? (Protip: because buyers of that gear aren't >> agitating for it) >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 >> > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From jra at baylink.com Fri Feb 28 14:04:18 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Feb 2014 09:04:18 -0500 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> Message-ID: <9023fcd7-5d48-40e9-a9cd-5b94cd5e9b3e@email.android.com> You mean, like Bcp38(.info)? On February 28, 2014 9:02:03 AM EST, Ray Soucy wrote: >I'm wondering how many operators don't have systems in place to >quickly and efficiently filter problem host systems. >I see a lot of talk of ACL usage, but not much about uRPF and black >hole filtering. > >There are a few white papers that are worth a read: > >http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf > >http://www.cisco.com/web/about/security/intelligence/urpf.pdf > >If you have uRPF enabled on all your access routers then you can >configure routing policy such that advertising a route for a specific >host system will trigger uRPF to drop the traffic at the first hop, in >hardware. > >This prevents you from having to maintain ACLs or even give out access >to routers. Instead, you can use a small router or daemon that >disables hosts by advertising them as a route (for example, we just >use a pair of small ISR 1841 routers for this); this in turn can be >tied into IPS or a web UI allowing your NOC to disable a problem host >at the first hop and prevent its traffic from propagating throughout >the network without having to know the overall architecture of the >network or determine the best place to apply an ACL. > >I've seen a lot of talk on trying to filter specific protocols, or >rate-limit, etc. but I really feel that isn't the appropriate action >to take. I think disabling a system that is a problem and notifying >its maintainer that they need to correct the issue is much more >sustainable. There are also limitations on how much can be done >through the use of ACLs. uRPF and black hole routing scale much >better, especially in response to a denial of service attack. > >When the NTP problems first started popping up, we saw incoming NTP of >several Gb, without the ability to quickly identify and filter this >traffic a lot of our users would have been dead in the water because >the firewalls they use just can't handle that much traffic; our >routers, on the other hand, have no problem throwing those packets >out. > >I only comment on this because one of the comments made to me was >"Can't we just use a firewall to block it?". It took me over an hour >to explain that the firewalls in use didn't have the capacity to >handle this level of traffic -- and when I tried to discuss hardware >vs. software filtering, I got a deer-in-the-headlights look. :-) > > >On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley >wrote: >> It depends on how many customers you have and what sort of contract >you have with them if any. A significant amount of attack traffic >comes from residential networks where a "one-size-fits-all" policy is >definitely best. >> >> On Feb 26, 2014, at 4:01 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Brandon Galbraith" >>> >>>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley > >>>> wrote: >>>>> More politely stated, it's not the responsibility of the operator >to >>>>> decide what belongs on the network and what doesn't. Users can run >any >>>>> services that's not illegal or even reuse ports for other >>>>> applications. >>> >>>> Blocking chargen at the edge doesn't seem to be outside of the >realm >>>> of possibilities. >>> >>> All of these conversations are variants of "how easy is it to set up >a >>> default ACL for loops, and then manage exceptions to it?". >>> >>> Assuming your gear permits it, I don't personally see all that much >>> Bad Actorliness in setting a relatively tight bidirectional ACL for >>> Random Edge Customers, and opening up -- either specific ports, or >>> just "to a less-/un-filtered ACL" on specific request. >>> >>> The question is -- as it is with BCP38 -- *can the edge gear handle >it*? >>> >>> And if not: why not? (Protip: because buyers of that gear aren't >>> agitating for it) >>> >>> Cheers, >>> -- jra >>> -- >>> Jay R. Ashworth Baylink >jra at baylink.com >>> Designer The Things I Think > RFC 2100 >>> Ashworth & Associates http://www.bcp38.info 2000 Land >Rover DII >>> St Petersburg FL USA BCP38: Ask For It By Name! +1 >727 647 1274 >>> >> >> > > > >-- >Ray Patrick Soucy >Network Engineer >University of Maine System > >T: 207-561-3526 >F: 207-561-3531 > >MaineREN, Maine's Research and Education Network >www.maineren.net -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From ryanshea at google.com Fri Feb 28 14:11:34 2014 From: ryanshea at google.com (Ryan Shea) Date: Fri, 28 Feb 2014 09:11:34 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: Keegan, don't get me wrong, I am not suggesting that even if version numbers were happily encoded in robust comments that this would be the same as actually digesting the configuration. If the function of checking using 'fancy versioning' is not an operational best practice, what do you suggest (all-knowing/singing/dancing tool which understands the configuration and your intent aside)? You say IF NTP or CPP were configured differently - with a large enough network there will always be configurations which have differences. With that as an operational constant, how do you determine which devices have the latest iteration of your line vty configuration. How often will a change not be rolled out to every router. This is again related to the size and churn of the network, but my practical estimation is that once you get into thousands of routers there will almost always be some that get missed. Comprehensive auditing is very important, and arguably more useful than version checking - but it requires that you make knowledgeable and complete assertions. I assert the my snmp config should look like the snmp snippet version 77 is easier to grok than "make sure our community string is not set to public" (and repeat hand-crafted audit logic for every segment of the config). What if some of the configs don't match the defined versions? This is why it may make sense to break snippets into functional areas. "Just fix it" might be sane for a banner, but squashing an interface mtu change that was put there for a reason could end in tears. I consider this bit out of the scope of the question, but yes it is another important problem. On Thu, Feb 27, 2014 at 10:03 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley > wrote: > > Putting aside the fact that snippets aren't a good way to conceptualize > deployed router code, my gut still tells me to question the question here. > The first is does this stuff change often enough to warrant a fancy > versioning solution? I have yet to see NTP deployed in a different way > than when I first learned to configure it. Next, when it does change how > often is it not rolled out to every router. If NTP or CPP or SNMP or some > other administrative option were configured differently across my > > sure, so you're saying that a large bit (maybe) of the router config > is 'one size fits all' and 'never changes' where 'never' is really > 'very infrequently'. > > sure, agreed... but there are parts of the config that do change more > frequently (depending on the network perhaps)... how do you go about > seeing which version / setup is deployed EXCEPT by building a > home-grown 'config parser' and seeing that 'what is deployed matches > mostly what I have in my config store for this > router/class-of-router/network' ? > > It's a shame that vendors of network equipment don't have to manage > large networks of their own equipment under constrained opex > environments (no fair comparing contracted work where you bill for > time + materials, that's the wrong incentive set)... I bet that'd get > them to fix stuff up right quick. > > network I would want to audit it and fix not version control. What if > some of the configs don't match the defined versions? It may be > better to create standard templates and version them in SVN or GIT and > then use config backups to track which devices have the standard > configs. There are some for pay tools that can search for certain > statements on various boxes and either alert or remediate when > differences are found. > > > > > > On Feb 26, 2014, at 4:22 PM, Ryan Shea wrote: > > > >> Howdy network operator cognoscenti, > >> > >> I'd love to hear your creative and workable solutions for a way to track > >> in-line the configuration revisions you have on your cisco-like devices. > >> Let me clearify/frame: > >> > >> You have a set of tested/approved configurations for your routers which > use > >> IOS style configuration. These configurations of course are always > refined > >> and updated. You break these pieces of configuration into logical > sections, > >> for example a configuration file for NTP configuration, a file for > control > >> plane filter and store these in some revision control system. Put aside > for > >> the moment whether this is a reasonable way to comprehend deployed > >> configurations. What methods do some of you use to know which version > of a > >> configuration you have deployed to a given router for auditing and > update > >> purposes? Remarks are a convenient way to do this for ACLs - but I don't > >> have similar mechanics for top level configurations. About a decade ago > I > >> thought I'd be super clever and encode versioning information into the > snmp > >> location - but that is just awful and there is a much better way > everyone > >> is using, right? Flexible commenting on other vendors/platforms make > this a > >> bit easier. > >> > >> Assume that this version encoding perfectly captures what is on the > router > >> and that no person is monkeying with the config... version 77 of the > >> control plane filter is the same everywhere. > > > > > From no.spam at comcast.net Fri Feb 28 14:49:19 2014 From: no.spam at comcast.net (Keegan Holley) Date: Fri, 28 Feb 2014 09:49:19 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: On Feb 28, 2014, at 9:11 AM, Ryan Shea wrote: > Keegan, don't get me wrong, I am not suggesting that even if version numbers were happily encoded in robust comments that this would be the same as actually digesting the configuration. If the function of checking using 'fancy versioning' is not an operational best practice, what do you suggest (all-knowing/singing/dancing tool which understands the configuration and your intent aside)? You say IF NTP or CPP were configured differently - with a large enough network there will always be configurations which have differences. With that as an operational constant, how do you determine which devices have the latest iteration of your line vty configuration. That?s what I mean. The things that lend well to to version tracking don?t tend to change much. How many ways are there to configure VTY lines, or NTP, or CPP, or even OSPF and if we?re talking about an access ACL why not just audit the configs to make sure that all the entries are there. Am I really going to care that one router has version 1.0 versus another router that has version 2.2.12 build9? It?s not source code.. > > How often will a change not be rolled out to every router. This is again related to the size and churn of the network, but my practical estimation is that once you get into thousands of routers there will almost always be some that get missed. Again, a router that was missed is a reason for audit and remediation not versioning. If you find a router with config missing does it really matter what version it?s on and when that version was valid? Not in my experience. > Comprehensive auditing is very important, and arguably more useful than version checking - but it requires that you make knowledgeable and complete assertions. I assert the my snmp config should look like the snmp snippet version 77 is easier to grok than "make sure our community string is not set to public" (and repeat hand-crafted audit logic for every segment of the config). There may be some differences, but those are normally due to equipment lifecycle, mergers/consolidations and such. It?s easy to refer to something as the config for a particular platform or company than a version number. This can be tracked in GIT or SVN. Even then there will not be constant changes. I?d lean towards standardization. So the equipment that cannot adhere to the defined standards probably won?t evolve much on it?s own. > > What if some of the configs don't match the defined versions? This is why it may make sense to break snippets into functional areas. "Just fix it" might be sane for a banner, but squashing an interface mtu change that was put there for a reason could end in tears. I consider this bit out of the scope of the question, but yes it is another important problem. I wasn?t saying just fix it. I was saying that router configs don?t lend well to versioning. With software for example, if something is different it might be a different version of that application with compatibility issues, dependencies, library issues, etc. When it?s a router config chances are someone fat-fingered something. Most of the time the best thing to do is to fix or at least alert on the error, not to record it as a valid config version. Again, this is for things that lend themselves to snippets. ACL?s, NTP, SNMP, CPP, even Spanning-tree. Not for things like interface IP?s or static routes that may be different across different boxes or location. If you?re referring to the latter I may have misunderstood your question.. > > > On Thu, Feb 27, 2014 at 10:03 PM, Christopher Morrow wrote: > On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley wrote: > > Putting aside the fact that snippets aren't a good way to conceptualize deployed router code, my gut still tells me to question the question here. The first is does this stuff change often enough to warrant a fancy versioning solution? I have yet to see NTP deployed in a different way than when I first learned to configure it. Next, when it does change how often is it not rolled out to every router. If NTP or CPP or SNMP or some other administrative option were configured differently across my > > sure, so you're saying that a large bit (maybe) of the router config > is 'one size fits all' and 'never changes' where 'never' is really > 'very infrequently'. > > sure, agreed... but there are parts of the config that do change more > frequently (depending on the network perhaps)... how do you go about > seeing which version / setup is deployed EXCEPT by building a > home-grown 'config parser' and seeing that 'what is deployed matches > mostly what I have in my config store for this > router/class-of-router/network' ? > > It's a shame that vendors of network equipment don't have to manage > large networks of their own equipment under constrained opex > environments (no fair comparing contracted work where you bill for > time + materials, that's the wrong incentive set)... I bet that'd get > them to fix stuff up right quick. > > network I would want to audit it and fix not version control. What if > some of the configs don't match the defined versions? It may be > better to create standard templates and version them in SVN or GIT and > then use config backups to track which devices have the standard > configs. There are some for pay tools that can search for certain > statements on various boxes and either alert or remediate when > differences are found. > > > > > > On Feb 26, 2014, at 4:22 PM, Ryan Shea wrote: > > > >> Howdy network operator cognoscenti, > >> > >> I'd love to hear your creative and workable solutions for a way to track > >> in-line the configuration revisions you have on your cisco-like devices. > >> Let me clearify/frame: > >> > >> You have a set of tested/approved configurations for your routers which use > >> IOS style configuration. These configurations of course are always refined > >> and updated. You break these pieces of configuration into logical sections, > >> for example a configuration file for NTP configuration, a file for control > >> plane filter and store these in some revision control system. Put aside for > >> the moment whether this is a reasonable way to comprehend deployed > >> configurations. What methods do some of you use to know which version of a > >> configuration you have deployed to a given router for auditing and update > >> purposes? Remarks are a convenient way to do this for ACLs - but I don't > >> have similar mechanics for top level configurations. About a decade ago I > >> thought I'd be super clever and encode versioning information into the snmp > >> location - but that is just awful and there is a much better way everyone > >> is using, right? Flexible commenting on other vendors/platforms make this a > >> bit easier. > >> > >> Assume that this version encoding perfectly captures what is on the router > >> and that no person is monkeying with the config... version 77 of the > >> control plane filter is the same everywhere. > > > > > From bicknell at ufp.org Fri Feb 28 15:24:37 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 28 Feb 2014 09:24:37 -0600 Subject: Managing IOS Configuration Snippets In-Reply-To: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: On Feb 27, 2014, at 7:38 PM, Keegan Holley wrote: > Putting aside the fact that snippets aren?t a good way to conceptualize deployed router code, my gut still tells me to question the question here. What I have always wanted is a way to group configuration, in particular by customer. Ideally with the ability to see it both as a unified view, and also as a per-customer view. For instance: customer AAAAA interface GigabitEthernet1/2/3.10 description AAAAA ip address 10.0.1.1 255.255.255.0 router bgp 1 neighbor 10.0.1.2 prefix-list AAAAA-in in ip prefix-list AAAAA-in 10.1.0.0/24 end customer BBBBB interface GigabitEthernet1/2/3.11 description BBBBB ip address 10.0.2.1 255.255.255.0 router bgp 1 neighbor 10.0.2.2 prefix-list BBBBB-in in ip prefix-list BBBBB-in 10.2.0.0/24 end Then I should be able to do: show run - Normal output like we see today, the "device" view. customer AAAAA show run - Same format as I have above, just config relevant to customer AAAAA. I can even see extending the tag to work with some other commands: customer AAAAA show int customer AAAAA show bgp ipv4 uni sum customer AAAAA show ip prefix-list The same functionality would work for snippets: customer ntp-servers-v1.0 ntp server 1.2.3.4 ntp server 1.2.3.5 ntp server 1.2.3.6 end Basically this follows the two modes in which engineers look at a device. Most of the time is configuring a specific customer, and wanting to be sure they are configured right; including the hard case of "no customer AAAAA", that is making sure all configuration for a specific customer is removed. The rest of the time is typically troubleshooting a network level problem where you want the device view we have today, I see interface Gig1/2/3 is dropping packets, "show run" to see who's configure on it sort of operations. I don't know of any platform that has implemented this sort of config framework though. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ryanshea at google.com Fri Feb 28 15:35:10 2014 From: ryanshea at google.com (Ryan Shea) Date: Fri, 28 Feb 2014 10:35:10 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: It sounds like your suggestion is to not check version numbers, write smart audits and react. Thinking of ACLs for example, version checking from a remark is a limted shortcut (but still very useful way) to validate distribution of an ACL. These things may change ~continuously. Grabbing a config and jamming that into some rancid rcs thing is different than intent version tracking. Our friends at Juniper (or the IOS-XR folks) seem to think the version control paradigm lends itself well to router configs, albeit at the whole-config level. Oh, and I think we're crossing streams here regarding versioning. I am not suggesting to take the configured state of the network, consider that proper intent, record it in a revision and then check for it in the future. I am assuming that the intent versions represent reviewed and tested configuration states by ops/neteng. Different across the fleet does not necessarily mean non-deterministic, so intent versioning can still be useful. I'm sure (not first-hand sure) that some of the other suggested templating systems could build parts of the expected config based on attributes of a device. On Fri, Feb 28, 2014 at 9:49 AM, Keegan Holley wrote: > > On Feb 28, 2014, at 9:11 AM, Ryan Shea wrote: > > Keegan, don't get me wrong, I am not suggesting that even if version > numbers were happily encoded in robust comments that this would be the same > as actually digesting the configuration. If the function of checking using > 'fancy versioning' is not an operational best practice, what do you suggest > (all-knowing/singing/dancing tool which understands the configuration and > your intent aside)? You say IF NTP or CPP were configured differently - > with a large enough network there will always be configurations which have > differences. With that as an operational constant, how do you determine > which devices have the latest iteration of your line vty configuration. > > > That?s what I mean. The things that lend well to to version tracking > don?t tend to change much. How many ways are there to configure VTY lines, > or NTP, or CPP, or even OSPF and if we?re talking about an access ACL why > not just audit the configs to make sure that all the entries are there. Am > I really going to care that one router has version 1.0 versus another > router that has version 2.2.12 build9? It?s not source code.. > > > How often will a change not be rolled out to every router. This is again > related to the size and churn of the network, but my practical estimation > is that once you get into thousands of routers there will almost always be > some that get missed. > > > Again, a router that was missed is a reason for audit and remediation not > versioning. If you find a router with config missing does it really matter > what version it?s on and when that version was valid? Not in my experience. > > Comprehensive auditing is very important, and arguably more useful than > version checking - but it requires that you make knowledgeable and complete > assertions. I assert the my snmp config should look like the snmp snippet > version 77 is easier to grok than "make sure our community string is not > set to public" (and repeat hand-crafted audit logic for every segment of > the config). > > > There may be some differences, but those are normally due to equipment > lifecycle, mergers/consolidations and such. It?s easy to refer to > something as the config for a particular platform or company than a version > number. This can be tracked in GIT or SVN. Even then there will not be > constant changes. I?d lean towards standardization. So the equipment that > cannot adhere to the defined standards probably won?t evolve much on it?s > own. > > > What if some of the configs don't match the defined versions? This is why > it may make sense to break snippets into functional areas. "Just fix it" > might be sane for a banner, but squashing an interface mtu change that was > put there for a reason could end in tears. I consider this bit out of the > scope of the question, but yes it is another important problem. > > > I wasn?t saying just fix it. I was saying that router configs don?t lend > well to versioning. With software for example, if something is different > it might be a different version of that application with compatibility > issues, dependencies, library issues, etc. When it?s a router config > chances are someone fat-fingered something. Most of the time the best > thing to do is to fix or at least alert on the error, not to record it as a > valid config version. Again, this is for things that lend themselves to > snippets. ACL?s, NTP, SNMP, CPP, even Spanning-tree. Not for things like > interface IP?s or static routes that may be different across different > boxes or location. If you?re referring to the latter I may have > misunderstood your question.. > > > > On Thu, Feb 27, 2014 at 10:03 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley >> wrote: >> > Putting aside the fact that snippets aren't a good way to conceptualize >> deployed router code, my gut still tells me to question the question here. >> The first is does this stuff change often enough to warrant a fancy >> versioning solution? I have yet to see NTP deployed in a different way >> than when I first learned to configure it. Next, when it does change how >> often is it not rolled out to every router. If NTP or CPP or SNMP or some >> other administrative option were configured differently across my >> >> sure, so you're saying that a large bit (maybe) of the router config >> is 'one size fits all' and 'never changes' where 'never' is really >> 'very infrequently'. >> >> sure, agreed... but there are parts of the config that do change more >> frequently (depending on the network perhaps)... how do you go about >> seeing which version / setup is deployed EXCEPT by building a >> home-grown 'config parser' and seeing that 'what is deployed matches >> mostly what I have in my config store for this >> router/class-of-router/network' ? >> >> It's a shame that vendors of network equipment don't have to manage >> large networks of their own equipment under constrained opex >> environments (no fair comparing contracted work where you bill for >> time + materials, that's the wrong incentive set)... I bet that'd get >> them to fix stuff up right quick. >> >> network I would want to audit it and fix not version control. What if >> some of the configs don't match the defined versions? It may be >> better to create standard templates and version them in SVN or GIT and >> then use config backups to track which devices have the standard >> configs. There are some for pay tools that can search for certain >> statements on various boxes and either alert or remediate when >> differences are found. >> > >> > >> > On Feb 26, 2014, at 4:22 PM, Ryan Shea wrote: >> > >> >> Howdy network operator cognoscenti, >> >> >> >> I'd love to hear your creative and workable solutions for a way to >> track >> >> in-line the configuration revisions you have on your cisco-like >> devices. >> >> Let me clearify/frame: >> >> >> >> You have a set of tested/approved configurations for your routers >> which use >> >> IOS style configuration. These configurations of course are always >> refined >> >> and updated. You break these pieces of configuration into logical >> sections, >> >> for example a configuration file for NTP configuration, a file for >> control >> >> plane filter and store these in some revision control system. Put >> aside for >> >> the moment whether this is a reasonable way to comprehend deployed >> >> configurations. What methods do some of you use to know which version >> of a >> >> configuration you have deployed to a given router for auditing and >> update >> >> purposes? Remarks are a convenient way to do this for ACLs - but I >> don't >> >> have similar mechanics for top level configurations. About a decade >> ago I >> >> thought I'd be super clever and encode versioning information into the >> snmp >> >> location - but that is just awful and there is a much better way >> everyone >> >> is using, right? Flexible commenting on other vendors/platforms make >> this a >> >> bit easier. >> >> >> >> Assume that this version encoding perfectly captures what is on the >> router >> >> and that no person is monkeying with the config... version 77 of the >> >> control plane filter is the same everywhere. >> > >> > >> > > > From rps at maine.edu Fri Feb 28 15:35:19 2014 From: rps at maine.edu (Ray Soucy) Date: Fri, 28 Feb 2014 10:35:19 -0500 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: <9023fcd7-5d48-40e9-a9cd-5b94cd5e9b3e@email.android.com> References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> <9023fcd7-5d48-40e9-a9cd-5b94cd5e9b3e@email.android.com> Message-ID: When I was looking at the website before I didn't really see any mention of uRPF, just the use of ACLs, maybe I missed it, but it's not encouraging if I can't spot it quickly. I just tried a search and the only thing that popped up was a how-to for a Cisco 7600 VXR. http://www.bcp38.info/index.php/HOWTO:CISCO:7200VXR On Fri, Feb 28, 2014 at 9:04 AM, Jay Ashworth wrote: > You mean, like Bcp38(.info)? > > > On February 28, 2014 9:02:03 AM EST, Ray Soucy wrote: >> >> I'm wondering how many operators don't have systems in place to >> quickly and efficiently filter problem host systems. >> I see a lot of talk of ACL usage, but not much about uRPF and black >> hole filtering. >> >> There are a few white papers that are worth a read: >> >> >> http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf >> >> http://www.cisco.com/web/about/security/intelligence/urpf.pdf >> >> If you have uRPF enabled on all your access routers then you can >> configure routing policy such that advertising a route for a specific >> host system will trigger uRPF to drop the traffic at the first hop, in >> hardware. >> This prevents you from having to maintain ACLs or even give out access >> to routers. Instead, you can use a small router or daemon that >> disables hosts by advertising them as a route (for example, we just >> use a pair of small ISR 1841 routers for this); this in turn can be >> tied into IPS or a web UI allowing your NOC to disable a problem host >> at the first hop and prevent its traffic from propagating throughout >> the network without having to know the overall architecture of the >> network or determine the best place to apply an ACL. >> >> I've seen a lot of talk on trying to filter specific protocols, or >> rate-limit, etc. but I really feel that isn't the appropriate action >> to take. I think disabling a system that is a problem and notifying >> its maintainer that they need to correct the issue is much more >> sustainable. There are also limitations on how much can be done >> through the use of ACLs. uRPF and black hole routing >> scale >> much >> better, especially in response to a denial of service attack. >> >> When the NTP problems first started popping up, we saw incoming NTP of >> several Gb, without the ability to quickly identify and filter this >> traffic a lot of our users would have been dead in the water because >> the firewalls they use just can't handle that much traffic; our >> routers, on the other hand, have no problem throwing those packets >> out. >> >> I only comment on this because one of the comments made to me was >> "Can't we just use a firewall to block it?". It took me over an hour >> to explain that the firewalls in use didn't have the capacity to >> handle this level of traffic -- and when I tried to discuss hardware >> vs. software filtering, I got a deer-in-the-headlights look. :-) >> >> >> On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley >> wrote: >>> >>> It depends on how many customers you have and what sort of contract you >>> have with them if any. A significant amount of attack traffic comes from >>> residential networks where a "one-size-fits-all" policy is definitely best. >>> >>> On Feb 26, 2014, at 4:01 PM, Jay Ashworth wrote: >>> >>>> ----- Original Message ----- >>>>> >>>>> From: "Brandon Galbraith" >>>> >>>> >>>>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley >>>>> wrote: >>>>>> >>>>>> More politely stated, it's not the responsibility of the operator to >>>>>> decide what belongs on the network and what doesn't. Users can run >>>>>> any >>>>>> services that's not illegal or even reuse ports for other >>>>>> applications. >>>> >>>> >>>>> Blocking chargen at the edge doesn't seem to be outside of the realm >>>>> of possibilities. >>>> >>>> >>>> All of these conversations are variants of "how easy is it to set up a >>>> default ACL for loops, and then manage exceptions to it?". >>>> >>>> Assuming your gear permits it, I don't personally see all that much >>>> Bad Actorliness in setting a relatively tight bidirectional ACL for >>>> Random Edge Customers, and opening up -- either specific ports, or >>>> just "to a less-/un-filtered ACL" on specific request >>>> . >>>> >>>> The question is -- as it is with BCP38 -- *can the edge gear handle >>>> it*? >>>> >>>> And if not: why not? (Protip: because buyers of that gear aren't >>>> agitating for it) >>>> >>>> Cheers, >>>> -- jra >>>> -- >>>> Jay R. Ashworth Baylink >>>> jra at baylink.com >>>> Designer The Things I Think >>>> RFC 2100 >>>> Ashworth & Associates http://www.bcp38.info 2000 Land >>>> Rover DII >>>> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 >>>> 647 1274 >>> >>> >> >> >> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From jerome at ceriz.fr Fri Feb 28 15:42:59 2014 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Fri, 28 Feb 2014 16:42:59 +0100 Subject: Filter on IXP In-Reply-To: <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> Message-ID: <5310AE83.7010300@ceriz.fr> Hi Chris, Le 23/02/2014 01:43, Chris Laffin a ?crit : > It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. Wasting ASIC ressources on IXP's dataplanes is a wet-dream for anyone willing to kill the network. IXP's neutrality is a key factor to maintain reasonable interconnexion density. Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. By the way, would anyone know how to generate OpenFlow messages to push such filters to member ports ? Would there be any smat way to do that on non-OpenFlow enabled dataplanes (C6k...) ? Best regards, -- J?r?me Nicolle +33 6 19 31 27 14 From jerome at ceriz.fr Fri Feb 28 15:50:47 2014 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Fri, 28 Feb 2014 16:50:47 +0100 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <20140223.182945.74711117.sthaug@nethelp.no> <4158B5FA-2BC0-4CCB-8FD2-600EF6DDE1E7@gmail.com> Message-ID: <5310B057.5030204@ceriz.fr> Hi Royce, Le 23/02/2014 20:48, Royce Williams a ?crit : > Newb question ... other than retrofitting, what stands in the way of > making BCP38 a condition of peering? Good point ! And simple answer : most peers wouldn't support the hassle yet, thus reducing peering density and interest. I operate a small IXP in southern France and none of my members is currently BCP38 compliant. Of 16 members only one is known to work on the issue. Funny thing beeing that most active members are also switching to Juniper routers and all had been contributing as NTP reflectors because of JunOS bugs. I'd rather consider implementing ACLs on member ports to filter-out illegitimate prefixes (cannot do OpenFlow on cheap L2 switches :( ) rather than making BCP38 compliance mandatory. Best regards, -- J?r?me Nicolle +33 6 19 31 27 14 From ryanshea at google.com Fri Feb 28 15:51:53 2014 From: ryanshea at google.com (Ryan Shea) Date: Fri, 28 Feb 2014 10:51:53 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: Isn't that framework called Juniper Op scripts? Run command which takes xml output of config (or other RPC) applies xslt, produces the output you describe. On Fri, Feb 28, 2014 at 10:24 AM, Leo Bicknell wrote: > > On Feb 27, 2014, at 7:38 PM, Keegan Holley wrote: > > > Putting aside the fact that snippets aren?t a good way to conceptualize > deployed router code, my gut still tells me to question the question here. > > What I have always wanted is a way to group configuration, in particular > by customer. Ideally with the ability to see it both as a unified view, > and also as a per-customer view. > > For instance: > > customer AAAAA > interface GigabitEthernet1/2/3.10 > description AAAAA > ip address 10.0.1.1 255.255.255.0 > router bgp 1 > neighbor 10.0.1.2 prefix-list AAAAA-in in > ip prefix-list AAAAA-in 10.1.0.0/24 > end > > customer BBBBB > interface GigabitEthernet1/2/3.11 > description BBBBB > ip address 10.0.2.1 255.255.255.0 > router bgp 1 > neighbor 10.0.2.2 prefix-list BBBBB-in in > ip prefix-list BBBBB-in 10.2.0.0/24 > end > > Then I should be able to do: > > show run - Normal output like we see today, the "device" view. > customer AAAAA show run - Same format as I have above, just config > relevant to customer AAAAA. > > I can even see extending the tag to work with some other commands: > > customer AAAAA show int > customer AAAAA show bgp ipv4 uni sum > customer AAAAA show ip prefix-list > > The same functionality would work for snippets: > > customer ntp-servers-v1.0 > ntp server 1.2.3.4 > ntp server 1.2.3.5 > ntp server 1.2.3.6 > end > > Basically this follows the two modes in which engineers look at a device. > Most of the time is configuring a specific customer, and wanting to be > sure they are configured right; including the hard case of "no customer > AAAAA", that is making sure all configuration for a specific customer is > removed. The rest of the time is typically troubleshooting a network level > problem where you want the device view we have today, I see interface > Gig1/2/3 is dropping packets, "show run" to see who's configure on it sort > of operations. > > I don't know of any platform that has implemented this sort of config > framework though. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From jra at baylink.com Fri Feb 28 16:00:51 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Feb 2014 11:00:51 -0500 (EST) Subject: Filter on IXP In-Reply-To: <5310AE83.7010300@ceriz.fr> Message-ID: <24595624.10364.1393603251352.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "J?r?me Nicolle" > Le 23/02/2014 01:43, Chris Laffin a ?crit : > > It would be really cool if peering exchanges could police ntp on > > their connected members. > > Well, THIS looks like the worst idea ever. Wasting ASIC ressources on > IXP's dataplanes is a wet-dream for anyone willing to kill the network. > IXP's neutrality is a key factor to maintain reasonable interconnexion > density. > > Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's > received routes to ingress _and_ egress ACLs on IXP ports would mitigate > the role of BCP38 offenders within member ports. It's almost like uRPF > in an intelligent and useable form. Interesting. Are you doing this? Planning it? Or at least researching how well it would work? > A noticeable side-effect is that members would be encouraged to announce > their entire customer-cones to ensure egress trafic from a non-exchanged > prefix would not be dropped on the IX's port. Don't they do this already? If you get something practical implemented on this topic, we'd be more than pleased to see it show up on bcp38.info; exchange points are the one major construct I hadn't included there, cause I didn't think it was actually practical to do it there. But then, I don't run one. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From niels=nanog at bakker.net Fri Feb 28 16:08:48 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 28 Feb 2014 17:08:48 +0100 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> Message-ID: <20140228160848.GA48842@burnout.tpb.net> * randy at psg.com (Randy Bush) [Thu 27 Feb 2014, 06:10 CET]: >is there any modern utility in chargen? No. But as we're not Apple, we don't get to decide what's good for the end user. Who knows, when CGNs become commonplace we'll start to run out of ephemeral ports and we'll have to start using ports < 1024 too. Would be a shame if their use were impeded by old ACLs lying around. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From jra at baylink.com Fri Feb 28 16:09:09 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Feb 2014 11:09:09 -0500 (EST) Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: Message-ID: <6658488.10366.1393603749755.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ray Soucy" > When I was looking at the website before I didn't really see any > mention of uRPF, just the use of ACLs, maybe I missed it, but it's not > encouraging if I can't spot it quickly. I just tried a search and the > only thing that popped up was a how-to for a Cisco 7600 VXR. Well, I do mention it, right there on the home page: """ BCP38 filtering to block these packets is most easily handled right at the very edge of the Internet: where customer links terminate in the first piece of provider 'aggregation' gear, like a router, DSLAM, or CMTS. Much to most of this gear already has a 'knob' which can be turned on, which simply drops these packets on the floor as they come in from the customer's PC. """ I simply didn't *name* the knob, cause the detail seemed out-of-scope for that context. Where it would get named would be on the "information for Audience" pages relevant to access providers, which I have not written because -- not being a provider -- I have insufficient background to be accurate. We welcome contributions from people in those positions... you, perhaps? Be bold! :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From erikm at buh.org Fri Feb 28 16:10:32 2014 From: erikm at buh.org (Erik Muller) Date: Fri, 28 Feb 2014 11:10:32 -0500 Subject: Managing IOS Configuration Snippets In-Reply-To: References: <73206985-A85C-4B6A-ACF9-4C997FB3FDE0@comcast.net> Message-ID: <5310B4F8.7050904@buh.org> On 2/28/14, 10:24 , Leo Bicknell wrote: > What I have always wanted is a way to group configuration, in particular by customer. Ideally with the ability to see it both as a unified view, and also as a per-customer view. > > For instance: > > customer AAAAA > interface GigabitEthernet1/2/3.10 > description AAAAA > ip address 10.0.1.1 255.255.255.0 > router bgp 1 > neighbor 10.0.1.2 prefix-list AAAAA-in in > ip prefix-list AAAAA-in 10.1.0.0/24 > end ... > Basically this follows the two modes in which engineers look at a device. Most of the time is configuring a specific customer, and wanting to be sure they are configured right; including the hard case of "no customer AAAAA", that is making sure all configuration for a specific customer is removed. The rest of the time is typically troubleshooting a network level problem where you want the device view we have today, I see interface Gig1/2/3 is dropping packets, "show run" to see who's configure on it sort of operations. > > I don't know of any platform that has implemented this sort of config framework though. It's not the cleanest, but in junos you can pretty much get this by defining a configuration group per customer and applying them all. Your RE may hate you at commit time, but I've seen this approach work quite well. -e From randy at psg.com Fri Feb 28 16:15:41 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Feb 2014 16:15:41 +0000 Subject: Filter on IXP In-Reply-To: <5310AE83.7010300@ceriz.fr> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> Message-ID: >> It would be really cool if peering exchanges could police ntp on >> their connected members. > Well, THIS looks like the worst idea ever. while i agree that this is an extremely stupid idea, clearly you have not been reading this list for very long randy From randy at psg.com Fri Feb 28 16:17:16 2014 From: randy at psg.com (Randy Bush) Date: Fri, 28 Feb 2014 16:17:16 +0000 Subject: Filter NTP traffic by packet size? In-Reply-To: <20140228160848.GA48842@burnout.tpb.net> References: <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> <20140228160848.GA48842@burnout.tpb.net> Message-ID: >> is there any modern utility in chargen? > Who knows, when CGNs become commonplace we'll start to run out of > ephemeral ports and we'll have to start using ports < 1024 too. > Would be a shame if their use were impeded by old ACLs lying around. woah! i did not suggest acls. i was assuming that one just disables the 'service'. randy From jerome at ceriz.fr Fri Feb 28 16:18:57 2014 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Fri, 28 Feb 2014 17:18:57 +0100 Subject: Filter on IXP In-Reply-To: <24595624.10364.1393603251352.JavaMail.root@benjamin.baylink.com> References: <24595624.10364.1393603251352.JavaMail.root@benjamin.baylink.com> Message-ID: <5310B6F1.702@ceriz.fr> Le 28/02/2014 17:00, Jay Ashworth a ?crit : >> From: "J?r?me Nicolle" >> Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's >> received routes to ingress _and_ egress ACLs on IXP ports would mitigate >> the role of BCP38 offenders within member ports. It's almost like uRPF >> in an intelligent and useable form. > > Interesting. Are you doing this? Planning it? Or at least researching > how well it would work? Juste seriously considering it on TOUIX. I'd propose it to Lyonix and France-IX too. >> A noticeable side-effect is that members would be encouraged to announce >> their entire customer-cones to ensure egress trafic from a non-exchanged >> prefix would not be dropped on the IX's port. > > Don't they do this already? Not to my knowledge. Some members are only announcing regional prefixes on smaller IXs. They could however exchange trafic originaing from any region of their networks. Best would be to differentiate announced prefixes from legitimately announcable prefixes, as registered to RIPEdb (as far as we're concerned). In a more global perspective, the extended best-practice could be to set ACLs as we generate prefix-lists, route-maps and route-filters for BGP downlinks and PNIs too. > If you get something practical implemented on this topic, we'd be more > than pleased to see it show up on bcp38.info; exchange points are the > one major construct I hadn't included there, cause I didn't think it was > actually practical to do it there. But then, I don't run one. I think the idea worth investigating, but I run a very small IXP and will most certainly be unable to fully investigate every potential side-effects on my own. I'll be reaching out to bigger ones in my next email. -- J?r?me Nicolle +33 6 19 31 27 14 From jerome at ceriz.fr Fri Feb 28 16:33:27 2014 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Fri, 28 Feb 2014 17:33:27 +0100 Subject: Filter on IXP In-Reply-To: References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org> Message-ID: <5310BA57.7070709@ceriz.fr> Hi Randy, Le 28/02/2014 17:15, Randy Bush a ?crit : > clearly you have not been reading this list for very long Well... Busted. All things considered, there surelly has been more stupid proposals. -- J?r?me Nicolle +33 6 19 31 27 14 From niels=nanog at bakker.net Fri Feb 28 16:47:20 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 28 Feb 2014 17:47:20 +0100 Subject: Filter NTP traffic by packet size? In-Reply-To: References: <4270A893-343F-437D-861C-2002046EFBFE@exchange.peer1.com> <530CCB98.9000701@ispn.net> <20F12F43-2ED3-4D78-BF13-4BF458651DDD@comcast.net> <20125.1393454025@turing-police.cc.vt.edu> <0FF7E5AA-05D1-4981-8E3E-DB9DEE5C3341@puck.nether.net> <20140228160848.GA48842@burnout.tpb.net> Message-ID: <20140228164720.GB48842@burnout.tpb.net> >>>is there any modern utility in chargen? >>Who knows, when CGNs become commonplace we'll start to run out of >>ephemeral ports and we'll have to start using ports < 1024 too. >>Would be a shame if their use were impeded by old ACLs lying >>around. * randy at psg.com (Randy Bush) [Fri 28 Feb 2014, 17:23 CET]: >woah! i did not suggest acls. i was assuming that one just >disables the 'service'. Oh, I'm sorry! I honestly thought this thread was about filtering as a way of mitigating abuse. Yes, of course one should not run the service, especially not UDP. -- Niels. From morrowc.lists at gmail.com Fri Feb 28 16:49:36 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Feb 2014 11:49:36 -0500 Subject: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?) In-Reply-To: References: <32090960.10160.1393448510556.JavaMail.root@benjamin.baylink.com> <49E4CDD8-2E59-44A1-BACE-9849B493AF97@comcast.net> Message-ID: On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy wrote: > If you have uRPF enabled on all your access routers then you can > configure routing policy such that advertising a route for a specific > host system will trigger uRPF to drop the traffic at the first hop, in > hardware. note that 'in hardware' is dependent upon the model used... note that stuffing 2k (or 5 or 10 or...) extra routes into your edge device could make it super unhappy. your points are valid for your designed network... they may not work everywhere. making the features you point out work better or be more widely known seems like a great idea though :) From nick at foobar.org Fri Feb 28 16:52:58 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 28 Feb 2014 16:52:58 +0000 Subject: Filter on IXP In-Reply-To: <5310AE83.7010300@ceriz.fr> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> Message-ID: <5310BEEA.9070403@foobar.org> On 28/02/2014 15:42, J?r?me Nicolle wrote: > Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's > received routes to ingress _and_ egress ACLs on IXP ports would mitigate > the role of BCP38 offenders within member ports. It's almost like uRPF > in an intelligent and useable form. this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. Nick From patrick at ianai.net Fri Feb 28 16:56:47 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 28 Feb 2014 11:56:47 -0500 Subject: Filter on IXP In-Reply-To: <5310BEEA.9070403@foobar.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> <5310BEEA.9070403@foobar.org> Message-ID: <0BBEDC07-B449-40C2-B017-0E0D66FFF309@ianai.net> On Feb 28, 2014, at 11:52 , Nick Hilliard wrote: > On 28/02/2014 15:42, J?r?me Nicolle wrote: >> Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's >> received routes to ingress _and_ egress ACLs on IXP ports would mitigate >> the role of BCP38 offenders within member ports. It's almost like uRPF >> in an intelligent and useable form. > > this will break horribly as soon as you have an IXP member which provides > transit to other multihomed networks. Or to anyone who doesn't announce their full downstream table to the route servers. Or to people who don't use route servers. Or to someone who does traffic engineering. Or .... -- TTFN, patrick From source_route at yahoo.com Fri Feb 28 16:58:02 2014 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 28 Feb 2014 08:58:02 -0800 (PST) Subject: Peering issue - Possible Juniper to Cisco issue Message-ID: <1393606682.9956.YahooMailNeo@web140703.mail.bf1.yahoo.com> To all, I (ASR1001) had an experience recently where the Telco (Juniper)?told me that I was sending them 1000+ routes when I attempted to re-establish a BGP session; subsequently they would not allow this and they refused the session. I?had no sync on and a prefix list so I was advertising only one route. Even though I hard reset the session?on my end the Telco for some reason kept seeing me send the routes. I finally called them and had them reset their end and the session came up right away. What the ... thx Philip From jerome at ceriz.fr Fri Feb 28 17:03:01 2014 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Fri, 28 Feb 2014 18:03:01 +0100 Subject: Filter on IXP In-Reply-To: <5310BEEA.9070403@foobar.org> References: <53066AE9.6010800@nuclearfallout.net> <6D158B4B-485E-42CD-9D0A-B816926D0F0E@puck.nether.net> <20140222074719.GA11705@pob.ytti.fi> <36E610E4-D6A3-4F28-B061-4257E33563B2@tzi.org> <5308BCF8.9060801@foobar.org>, <5308CA7A.4020905@mykolab.com> <922B21F2-D3E9-41C4-A3CE-39D8B4565842@exchange.peer1.com> <5310AE83.7010300@ceriz.fr> <5310BEEA.9070403@foobar.org> Message-ID: <5310C145.6080402@ceriz.fr> Le 28/02/2014 17:52, Nick Hilliard a ?crit : > this will break horribly as soon as you have an IXP member which provides > transit to other multihomed networks. It could break if filters are based on announced prefixes. That's preciselly why uRPF is often useless. On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. -- J?r?me Nicolle +33 6 19 31 27 14 From simon at slimey.org Fri Feb 28 17:11:46 2014 From: simon at slimey.org (Simon Lockhart) Date: Fri, 28 Feb 2014 17:11:46 +0000 Subject: Peering issue - Possible Juniper to Cisco issue In-Reply-To: <1393606682.9956.YahooMailNeo@web140703.mail.bf1.yahoo.com> References: <1393606682.9956.YahooMailNeo@web140703.mail.bf1.yahoo.com> Message-ID: <20140228171145.GH5282@virtual.bogons.net> On Fri Feb 28, 2014 at 08:58:02AM -0800, Philip Lavine wrote: > I?had no sync on and a prefix list so I was advertising only one route. Even > though I hard reset the session?on my end the Telco for some reason kept > seeing me send the routes. I finally called them and had them reset their end > and the session came up right away. This sounds like you tripped a Max-Prefix limit by advertising too many prefixes at some point (maybe when you first configured the session, when it's easy for the session to come up before you've configured the prefix list). Once you've tripped Max-Prefix, you won't be able to establish a new connection to them until they reset their end. Simon From mloftis at wgops.com Fri Feb 28 17:13:59 2014 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 28 Feb 2014 09:13:59 -0800 Subject: Peering issue - Possible Juniper to Cisco issue In-Reply-To: <1393606682.9956.YahooMailNeo@web140703.mail.bf1.yahoo.com> References: <1393606682.9956.YahooMailNeo@web140703.mail.bf1.yahoo.com> Message-ID: On Fri, Feb 28, 2014 at 8:58 AM, Philip Lavine wrote: > To all, > > I (ASR1001) had an experience recently where the Telco (Juniper) told me that I was sending them 1000+ routes when I attempted to re-establish a BGP session; subsequently they would not allow this and they refused the session. > > I had no sync on and a prefix list so I was advertising only one route. Even though I hard reset the session on my end the Telco for some reason kept seeing me send the routes. I finally called them and had them reset their end and the session came up right away. > > What the ... If you leaked once and they have a teardown setup on the Juniper end w/o a timeout, it won't let the neighbor reconnect until the session is cleared. I've seen in IOS 15.x just a few days ago where it had stuck advertising routes that it shouldn't be, though that was between two Sup720 based pieces of gear, so probably unrelated (just a data point that it can/does happen in IOS in general where it's advertising routes that it insists it isn't) > > thx > > Philip > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From cscora at apnic.net Fri Feb 28 18:11:55 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Mar 2014 04:11:55 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201402281811.s1SIBtmw021367@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 01 Mar, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 484203 Prefixes after maximum aggregation: 191504 Deaggregation factor: 2.53 Unique aggregates announced to Internet: 239504 Total ASes present in the Internet Routing Table: 46226 Prefixes per ASN: 10.47 Origin-only ASes present in the Internet Routing Table: 35597 Origin ASes announcing only one prefix: 16401 Transit ASes present in the Internet Routing Table: 6037 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1858 Unregistered ASNs in the Routing Table: 487 Number of 32-bit ASNs allocated by the RIRs: 6020 Number of 32-bit ASNs visible in the Routing Table: 4592 Prefixes from 32-bit ASNs in the Routing Table: 14841 Number of bogon 32-bit ASNs visible in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 397 Number of addresses announced to Internet: 2656597764 Equivalent to 158 /8s, 88 /16s and 119 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.8 Total number of prefixes smaller than registry allocations: 169116 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 114986 Total APNIC prefixes after maximum aggregation: 34485 APNIC Deaggregation factor: 3.33 Prefixes being announced from the APNIC address blocks: 117592 Unique aggregates announced from the APNIC address blocks: 49413 APNIC Region origin ASes present in the Internet Routing Table: 4895 APNIC Prefixes per ASN: 24.02 APNIC Region origin ASes announcing only one prefix: 1226 APNIC Region transit ASes present in the Internet Routing Table: 855 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 848 Number of APNIC addresses announced to Internet: 731200640 Equivalent to 43 /8s, 149 /16s and 60 /24s Percentage of available APNIC address space announced: 85.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 165723 Total ARIN prefixes after maximum aggregation: 82909 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 167138 Unique aggregates announced from the ARIN address blocks: 77636 ARIN Region origin ASes present in the Internet Routing Table: 16149 ARIN Prefixes per ASN: 10.35 ARIN Region origin ASes announcing only one prefix: 6118 ARIN Region transit ASes present in the Internet Routing Table: 1669 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 69 Number of ARIN addresses announced to Internet: 1065895808 Equivalent to 63 /8s, 136 /16s and 71 /24s Percentage of available ARIN address space announced: 56.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 122018 Total RIPE prefixes after maximum aggregation: 61467 RIPE Deaggregation factor: 1.99 Prefixes being announced from the RIPE address blocks: 126008 Unique aggregates announced from the RIPE address blocks: 79900 RIPE Region origin ASes present in the Internet Routing Table: 17624 RIPE Prefixes per ASN: 7.15 RIPE Region origin ASes announcing only one prefix: 8308 RIPE Region transit ASes present in the Internet Routing Table: 2857 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2636 Number of RIPE addresses announced to Internet: 655827588 Equivalent to 39 /8s, 23 /16s and 34 /24s Percentage of available RIPE address space announced: 95.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 54676 Total LACNIC prefixes after maximum aggregation: 9987 LACNIC Deaggregation factor: 5.47 Prefixes being announced from the LACNIC address blocks: 60535 Unique aggregates announced from the LACNIC address blocks: 28074 LACNIC Region origin ASes present in the Internet Routing Table: 2074 LACNIC Prefixes per ASN: 29.19 LACNIC Region origin ASes announcing only one prefix: 547 LACNIC Region transit ASes present in the Internet Routing Table: 422 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1028 Number of LACNIC addresses announced to Internet: 151983232 Equivalent to 9 /8s, 15 /16s and 20 /24s Percentage of available LACNIC address space announced: 90.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11852 Total AfriNIC prefixes after maximum aggregation: 2619 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 12533 Unique aggregates announced from the AfriNIC address blocks: 4155 AfriNIC Region origin ASes present in the Internet Routing Table: 699 AfriNIC Prefixes per ASN: 17.93 AfriNIC Region origin ASes announcing only one prefix: 202 AfriNIC Region transit ASes present in the Internet Routing Table: 149 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 11 Number of AfriNIC addresses announced to Internet: 51371776 Equivalent to 3 /8s, 15 /16s and 223 /24s Percentage of available AfriNIC address space announced: 51.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2988 11580 895 Korea Telecom 17974 2756 902 88 PT Telekomunikasi Indonesia 7545 2188 320 116 TPG Telecom Limited 4755 1839 396 197 TATA Communications formerly 9829 1593 1283 39 National Internet Backbone 9583 1313 102 534 Sify Limited 7552 1235 1082 13 Viettel Corporation 9498 1226 309 69 BHARTI Airtel Ltd. 4808 1181 2123 359 CNCGROUP IP network China169 24560 1108 379 174 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3022 3688 53 BellSouth.net Inc. 22773 2320 2938 140 Cox Communications Inc. 1785 2164 692 131 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1687 1673 576 Charter Communications 4323 1624 1089 412 tw telecom holdings, inc. 701 1492 11174 763 MCI Communications Services, 30036 1380 298 560 Mediacom Communications Corp 6983 1301 772 582 ITC^Deltacom 7018 1288 18002 834 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1796 544 16 OJSC "Vimpelcom" 34984 1408 243 222 TELLCOM ILETISIM HIZMETLERI A 20940 1260 475 951 Akamai International B.V. 13188 1048 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 893 370 41 Bezeq International-Ltd 6849 826 361 35 JSC "Ukrtelecom" 6830 774 2331 425 Liberty Global Operations B.V 12479 713 798 51 France Telecom Espana SA 35819 563 634 74 Bayanat Al-Oula For Network S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3494 1938 93 NET Servi?os de Comunica??o S 10620 2770 442 183 Telmex Colombia S.A. 18881 1907 972 21 Global Village Telecom 7303 1751 1172 223 Telecom Argentina S.A. 8151 1375 2884 417 Uninet S.A. de C.V. 6503 945 434 62 Axtel, S.A.B. de C.V. 11830 869 364 15 Instituto Costarricense de El 27947 851 101 89 Telconet S.A 7738 846 1626 39 Telemar Norte Leste S.A. 3816 781 315 125 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1638 240 6 Sudanese Mobile Telephone (ZA 24863 920 376 28 Link Egypt (Link.NET) 6713 602 685 28 Office National des Postes et 8452 508 958 13 TE-AS 24835 299 144 9 Vodafone Data 36992 264 783 24 ETISALAT MISR 3741 247 921 208 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29571 204 22 16 Cote d'Ivoire Telecom 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3494 1938 93 NET Servi?os de Comunica??o S 6389 3022 3688 53 BellSouth.net Inc. 4766 2988 11580 895 Korea Telecom 10620 2770 442 183 Telmex Colombia S.A. 17974 2756 902 88 PT Telekomunikasi Indonesia 22773 2320 2938 140 Cox Communications Inc. 7545 2188 320 116 TPG Telecom Limited 1785 2164 692 131 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 18881 1907 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3022 2969 BellSouth.net Inc. 17974 2756 2668 PT Telekomunikasi Indonesia 10620 2770 2587 Telmex Colombia S.A. 22773 2320 2180 Cox Communications Inc. 4766 2988 2093 Korea Telecom 7545 2188 2072 TPG Telecom Limited 1785 2164 2033 PaeTec Communications, Inc. 18881 1907 1886 Global Village Telecom 18566 2048 1870 MegaPath Corporation 8402 1796 1780 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:30 /11:90 /12:255 /13:475 /14:953 /15:1652 /16:12860 /17:6749 /18:11490 /19:23756 /20:33607 /21:36192 /22:51760 /23:45021 /24:257024 /25:796 /26:950 /27:436 /28:12 /29:17 /30:7 /31:1 /32:42 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 6389 1696 3022 BellSouth.net Inc. 36998 1599 1638 Sudanese Mobile Telephone (ZA 22773 1560 2320 Cox Communications Inc. 8402 1477 1796 OJSC "Vimpelcom" 30036 1218 1380 Mediacom Communications Corp 11492 1165 1205 CABLE ONE, INC. 1785 1159 2164 PaeTec Communications, Inc. 6983 1039 1301 ITC^Deltacom 22561 990 1287 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:976 2:781 3:3 4:16 5:913 6:19 8:650 12:1850 13:4 14:953 15:9 16:3 17:25 18:21 20:35 23:698 24:1720 27:1753 31:1582 32:44 33:2 34:5 36:119 37:1935 38:929 39:4 40:193 41:3097 42:243 44:18 46:2160 47:13 49:678 50:911 52:12 54:56 55:7 57:26 58:1160 59:594 60:375 61:1529 62:1256 63:1979 64:4333 65:2244 66:4196 67:2070 68:1035 69:3300 70:840 71:469 72:1959 74:2663 75:311 76:392 77:1200 78:1045 79:694 80:1297 81:1126 82:669 83:744 84:750 85:1262 86:402 87:1072 88:521 89:1658 90:151 91:5732 92:665 93:1669 94:2050 95:1484 96:537 97:352 98:1072 99:41 100:35 101:785 103:4288 105:534 106:166 107:501 108:543 109:2096 110:981 111:1255 112:620 113:823 114:874 115:1074 116:1039 117:884 118:1280 119:1312 120:353 121:789 122:1918 123:1258 124:1443 125:1452 128:643 129:242 130:359 131:659 132:357 133:157 134:320 135:74 136:247 137:310 138:345 139:159 140:207 141:358 142:557 143:419 144:497 145:99 146:600 147:455 148:794 149:340 150:150 151:582 152:421 153:204 154:91 155:462 156:327 157:368 158:220 159:866 160:355 161:475 162:1193 163:217 164:681 165:611 166:281 167:597 168:1044 169:125 170:1198 171:195 172:18 173:1641 174:679 175:589 176:1470 177:2783 178:1980 179:537 180:1630 181:997 182:1451 183:495 184:698 185:1314 186:2816 187:1447 188:1987 189:1293 190:7468 191:108 192:7110 193:5442 194:4011 195:3366 196:1331 197:1103 198:4921 199:5572 200:6051 201:2666 202:8961 203:8889 204:4656 205:2659 206:2911 207:2881 208:3979 209:3707 210:3085 211:1699 212:2218 213:1996 214:879 215:84 216:5500 217:1708 218:565 219:320 220:1293 221:595 222:336 223:604 End of report From eric-list at truenet.com Fri Feb 28 19:27:06 2014 From: eric-list at truenet.com (eric-list at truenet.com) Date: Fri, 28 Feb 2014 14:27:06 -0500 Subject: Any experience with Comcast digital voice for OOB (offlist is fine) Message-ID: <03cf01cf34bb$1127e670$3377b350$@truenet.com> Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 From cidr-report at potaroo.net Fri Feb 28 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Feb 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201402282200.s1SM00IQ035746@wattle.apnic.net> This report has been generated at Fri Feb 28 21:13:43 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-02-14 490117 276717 22-02-14 490278 276399 23-02-14 490404 276168 24-02-14 490498 276712 25-02-14 491489 276513 26-02-14 491118 276545 27-02-14 491390 276447 28-02-14 491597 276393 AS Summary 46405 Number of ASes in routing system 19025 Number of ASes announcing only one prefix 3500 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A. 119657728 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 28Feb14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 491516 276325 215191 43.8% All ASes AS28573 3500 108 3392 96.9% NET Servi?os de Comunica??o S.A. AS6389 3021 56 2965 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2755 190 2565 93.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2988 904 2084 69.7% KIXS-AS-KR Korea Telecom AS18881 1907 25 1882 98.7% Global Village Telecom AS1785 2164 411 1753 81.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 2772 1200 1572 56.7% Telmex Colombia S.A. AS36998 1638 99 1539 94.0% SDN-MOBITEL AS18566 2048 565 1483 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2932 1513 1419 48.4% TWTC - tw telecom holdings, inc. AS7303 1751 450 1301 74.3% Telecom Argentina S.A. AS4755 1839 624 1215 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 2189 1037 1152 52.6% TPG-INTERNET-AP TPG Telecom Limited AS7552 1260 158 1102 87.5% VIETEL-AS-AP Viettel Corporation AS22561 1287 227 1060 82.4% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1593 663 930 58.4% BSNL-NIB National Internet Backbone AS22773 2324 1394 930 40.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4808 1181 398 783 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS35908 871 104 767 88.1% VPLSNET - Krypt Technologies AS18101 917 163 754 82.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1108 375 733 66.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS701 1492 763 729 48.9% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS4788 978 259 719 73.5% TMNET-AS-AP TM Net, Internet Service Provider AS6983 1301 582 719 55.3% ITCDELTA - ITC^Deltacom AS8151 1384 666 718 51.9% Uninet S.A. de C.V. AS7738 846 148 698 82.5% Telemar Norte Leste S.A. AS855 754 57 697 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 1028 361 667 64.9% SEEDNET Digital United Inc. AS9808 941 286 655 69.6% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS6147 765 113 652 85.2% Telefonica del Peru S.A.A. Total 51534 13899 37635 73.0% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS3356 LEVEL3 Level 3 Communications 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc. 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.229.186.0/24 AS56967 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 103.226.220.0/22 AS38719 AUSTDOM-AS-AP Aust Domains International Pty Ltd. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.85.1.0/24 AS29571 CITelecom-AS 172.85.2.0/24 AS29571 CITelecom-AS 172.85.3.0/24 AS29571 CITelecom-AS 172.86.0.0/24 AS29571 CITelecom-AS 172.87.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.49.68.0/22 AS16265 FIBERRING LeaseWeb B.V. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.26.219.0/24 AS38913 ENTER-NET-TEAM-AS Enter-Net Team SRL 193.28.14.0/24 AS34309 LINK11 Link11 GmbH 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.33.252.0/23 AS3356 LEVEL3 Level 3 Communications 193.36.229.0/24 AS15404 COLT Technology Services Group Limited 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd 193.84.187.0/24 AS16276 OVH OVH Systems 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS 193.111.229.0/24 AS3356 LEVEL3 Level 3 Communications 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A. 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.26.0/24 AS16095 JAYNET jay.net a/s 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.227.236.0/23 AS3356 LEVEL3 Level 3 Communications 193.243.166.0/24 AS44093 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd. 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd. 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd. 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.55.104.0/23 AS7244 ALAMEDANET - Alameda Networks 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB 194.156.179.0/24 AS3209 VODANET Vodafone GmbH 194.176.123.0/24 AS28717 ZENSYSTEMS-AS Zen Systems A/S 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.8.48.0/23 AS3356 LEVEL3 Level 3 Communications 195.8.48.0/24 AS3356 LEVEL3 Level 3 Communications 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.85.201.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.178.120.0/23 AS39385 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 195.244.18.0/23 AS3356 LEVEL3 Level 3 Communications 195.245.198.0/24 AS6714 ATOMNET GTS Poland Sp. z o.o. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.196.64.0/24 AS26977 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.91.164.0/22 AS46099 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.203.80.0/20 AS27021 216.203.80.0/21 AS27021 216.203.87.0/24 AS27021 216.203.88.0/21 AS27021 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 28 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Feb 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201402282200.s1SM01s5035755@wattle.apnic.net> BGP Update Report Interval: 20-Feb-14 -to- 27-Feb-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 41608 1.8% 41.4 -- BSNL-NIB National Internet Backbone 2 - AS8402 34531 1.5% 39.3 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS28573 25671 1.1% 14.0 -- NET Servi?os de Comunica??o S.A. 4 - AS7552 23689 1.0% 18.6 -- VIETEL-AS-AP Viettel Corporation 5 - AS4538 23548 1.0% 42.4 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS10620 23159 1.0% 9.1 -- Telmex Colombia S.A. 7 - AS60349 22167 1.0% 335.9 -- PBL-KIEV-AS Partners. Business & Law Ltd. 8 - AS13118 20859 0.9% 496.6 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS45169 19710 0.9% 1314.0 -- GLOBAL-DESCON-AS-AP Descon Limited 10 - AS41691 19286 0.8% 964.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 11 - AS4775 19115 0.8% 490.1 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS29571 16738 0.7% 91.5 -- CITelecom-AS 13 - AS11976 15440 0.7% 1403.6 -- FIDN - Fidelity Communication International Inc. 14 - AS8151 14745 0.6% 14.1 -- Uninet S.A. de C.V. 15 - AS17974 14283 0.6% 5.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS36998 13986 0.6% 8.6 -- SDN-MOBITEL 17 - AS50710 13831 0.6% 61.5 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 18 - AS28024 13013 0.6% 41.6 -- Nuevatel PCS de Bolivia S.A. 19 - AS23893 12031 0.5% 308.5 -- BPL-BD House No:03, Road no: 23/A 20 - AS27738 12012 0.5% 20.8 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6459 7758 0.3% 7758.0 -- TRANSBEAM - I-2000, Inc. 2 - AS6629 8669 0.4% 4334.5 -- NOAA-AS - NOAA 3 - AS16561 3354 0.1% 3354.0 -- ARIBANETWORK Ariba Inc. Autonomous System 4 - AS39575 2583 0.1% 2583.0 -- SIBINTEK-SAMARA-AS Siberian Internet Company 5 - AS54465 7439 0.3% 2479.7 -- QPM-AS-1 - QuickPlay Media Inc. 6 - AS2899 2169 0.1% 2169.0 -- SPRO-NET - SOLUTION PRO 7 - AS14287 10364 0.5% 1727.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 8 - AS11976 15440 0.7% 1403.6 -- FIDN - Fidelity Communication International Inc. 9 - AS45169 19710 0.9% 1314.0 -- GLOBAL-DESCON-AS-AP Descon Limited 10 - AS56488 1075 0.1% 1075.0 -- E-GROUP-AS OOO E-GROUP 11 - AS41691 19286 0.8% 964.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 12 - AS62431 816 0.0% 816.0 -- NCSC-IE-AS National Cyber Security Centre 13 - AS11054 11515 0.5% 719.7 -- LIVEPERSON LivePerson, Inc 14 - AS24933 1371 0.1% 685.5 -- MINXS-AS MILLENNIUMS.NET GmbH 15 - AS22688 644 0.0% 644.0 -- DOLGENCORP - Dollar General Corporation 16 - AS60345 1204 0.1% 602.0 -- NBITI-AS Nahjol Balagheh International Research Institution 17 - AS37367 582 0.0% 582.0 -- CALLKEY 18 - AS52069 581 0.0% 581.0 -- VCT-AS Vladivostok Container Terminal Ltd. 19 - AS49847 2839 0.1% 567.8 -- RAYAZMA-AS Pardazeshgar Rayazma Ltd. 20 - AS11486 3371 0.1% 561.8 -- COLO-PREM-VZB - Verizon Online LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 20547 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 89.221.206.0/24 19175 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 5 - 192.58.232.0/24 8667 0.3% AS6629 -- NOAA-AS - NOAA 6 - 67.210.190.0/23 8261 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 7 - 205.247.12.0/24 7758 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 8 - 206.152.15.0/24 7437 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 9 - 67.210.188.0/23 7166 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 10 - 78.109.192.0/20 7011 0.3% AS25184 -- AFRANET AFRANET Co. Tehran, Iran 11 - 103.11.61.0/24 6741 0.3% AS9387 -- AUGERE-PK AUGERE-Pakistan 12 - 216.109.107.0/24 6707 0.3% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 13 - 200.23.126.0/24 6339 0.3% AS8151 -- Uninet S.A. de C.V. 14 - 199.187.118.0/24 5361 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 15 - 113.11.132.0/24 4538 0.2% AS17658 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 16 - 216.57.5.0/24 4263 0.2% AS12006 -- BROADVIEWNET-AS-12006 - Broadview Networks, Inc. 17 - 69.38.178.0/24 3898 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 18 - 2.93.235.0/24 3103 0.1% AS8402 -- CORBINA-AS OJSC "Vimpelcom" 19 - 72.52.128.0/17 2677 0.1% AS32244 -- LIQUID-WEB-INC - Liquid Web, Inc. 20 - 213.128.220.0/22 2583 0.1% AS39575 -- SIBINTEK-SAMARA-AS Siberian Internet Company Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From Matthew.Black at csulb.edu Fri Feb 28 22:51:30 2014 From: Matthew.Black at csulb.edu (Matthew Black) Date: Fri, 28 Feb 2014 22:51:30 +0000 Subject: Are DomainKeys for e-mail signing dead? Message-ID: Apologies if I slept through prior discussions on the topic. E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the following error: #####@YAHOO.COM Last error: 5.7.9 554 5.7.9 Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html I note: 1. The e-mail error (5.7.9) references the link http://postmaster.yahoo.com/errors/postmaster-28.html. 2. That Yahoo page does not mention error 5.7.9, but references a similar error 5.7.4 "Message not accepted for policy reasons." 3. It appears that Yahoo wants inbound messages signed using DomainKeys technology. 4. Yahoo is the lead inventor of DomainKeys, along with Cicso, PGP, and Sendmail. 5. L-Soft LISTSERV manuals and Yahoo both refer to the website http://domainkeys.sourceforge.net/. 6. When I click on the Documentation and DomainKeys Implementors Mailing List links on that page, I get page not found. 7. A 2007 USA Today Article (http://usatoday30.usatoday.com/tech/products/cnet/2007-05-23-domainkeys-anti-spam_N.htm) mentions that DomainKeys have not been widely adopted. 8. A basic Google search for DomainKeys comes up with no recent articles. One website (http://blog.wordtothewise.com/2011/09/dkim-is-done/) says that DKIM/DomainKeys are dead. Are the rumors of the death of DomainKeys premature? If not, is anyone from Yahoo listening? matthew black california state university, long beach From ops.lists at gmail.com Fri Feb 28 23:36:34 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 1 Mar 2014 05:06:34 +0530 Subject: Are DomainKeys for e-mail signing dead? In-Reply-To: References: Message-ID: On Saturday, March 1, 2014, Matthew Black wrote: > Apologies if I slept through prior discussions on the topic. > E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the > following error: Alive and well after the standard evolved. Google DKIM and then DMARC. I doubt anything as antique as listserv supports either, so route its inbound / outbound mail through a gateway running postfix / sendmail etc. --srs -- --srs (iPad) From johnl at iecc.com Fri Feb 28 23:39:17 2014 From: johnl at iecc.com (John Levine) Date: 28 Feb 2014 23:39:17 -0000 Subject: Are DomainKeys for e-mail signing dead? In-Reply-To: Message-ID: <20140228233917.34159.qmail@joyce.lan> In article you write: >Apologies if I slept through prior discussions on the topic. Regardless of what various aging web pages and un-upgraded mail software might say, Domainkeys is as dead as a doornail, even at Yahoo. Use DKIM, you'll be happier, even at Yahoo. R's, John From selina.harrington at icann.org Fri Feb 28 22:06:48 2014 From: selina.harrington at icann.org (Selina Harrington) Date: Fri, 28 Feb 2014 14:06:48 -0800 Subject: IANA AS Numbers registry update Message-ID: The IANA AS Numbers registry has been updated to reflect the allocation of 2 blocks to the RIPE NCC in 2014-02-28: 200192-201215 201216-202239 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Selina Harrington ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 ******************************************* From zwicky at yahoo-inc.com Fri Feb 28 23:11:39 2014 From: zwicky at yahoo-inc.com (Elizabeth Zwicky) Date: Fri, 28 Feb 2014 23:11:39 +0000 Subject: Are DomainKeys for e-mail signing dead? In-Reply-To: References: Message-ID: 5.7.4 means "you told us not to accept your mail unless it was validly signed and it is not". The solution for this is to make sure that mail with a From: in a domain that requires this is validly signed. Yahoo does not care whether you use DKIM or DomainKeys for this purpose; other people may well like DKIM better, making it more fun. I note that the help page you reference mentions DKIM and DomainKeys together every time. If your LISTSERV -- gets mail from somebody with a domain that requires their mail to be validly signed (for instance, via DMARC) -- leaves that sender's address in the From: line -- and breaks the DKIM signature then the mail will not deliver to recipients at Yahoo. Your choices are: -- ask (or force) the sender to join the LISTSERV from a sending domain that does not do this -- modify the From: to not be in the sender's domain -- avoid breaking the DKIM signature -- let the mail fail Elizabeth On 2/28/14 2:51 PM, "Matthew Black" wrote: >Apologies if I slept through prior discussions on the topic. > > > >E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the >following error: > > > >#####@YAHOO.COM > > Last error: 5.7.9 554 5.7.9 Message not accepted for policy reasons. >See http://postmaster.yahoo.com/errors/postmaster-28.html > > > >I note: > > > >1. The e-mail error (5.7.9) references the link >http://postmaster.yahoo.com/errors/postmaster-28.html. > >2. That Yahoo page does not mention error 5.7.9, but references a >similar error 5.7.4 "Message not accepted for policy reasons." > >3. It appears that Yahoo wants inbound messages signed using >DomainKeys technology. > >4. Yahoo is the lead inventor of DomainKeys, along with Cicso, PGP, >and Sendmail. > >5. L-Soft LISTSERV manuals and Yahoo both refer to the website >http://domainkeys.sourceforge.net/. > >6. When I click on the Documentation and DomainKeys Implementors >Mailing List links on that page, I get page not found. > >7. A 2007 USA Today Article >(http://usatoday30.usatoday.com/tech/products/cnet/2007-05-23-domainkeys-a >nti-spam_N.htm) mentions that DomainKeys have not been widely adopted. > >8. A basic Google search for DomainKeys comes up with no recent >articles. One website >(http://blog.wordtothewise.com/2011/09/dkim-is-done/) says that >DKIM/DomainKeys are dead. > > > > > >Are the rumors of the death of DomainKeys premature? If not, is anyone >from Yahoo listening? > > > >matthew black > >california state university, long beach > > > >