Re: [Nanog-futures] an alternate proposal forNewNOG's membership structure
snip http://www.nanog.org/meetings/attending/wavingfee/studentreg.php doesn't indicate that they need to be full time, so I guess they just have to be a college or university student. Period. Yes? why only university? wazza matter with the younger set? i have worked with some bitchin' good 15 year olds that became senior geeks over the years. This is exactly the problem. We have to qualify what a student is and have a verification mechanism. It can be as simple as a school ID, or as complex as a copy of a transcript showing credit hours, or a call to the institution to verify enrollment. Without this, many people may say they are students to get a cheaper rate. I don't understand what is so hard about this. EVERY meeting/club/organization that I have been involved in that has a student rate has a qualification for the rate. We just need to decide what it means (In terms of membership restrictions), and how to verify (or not verify) the status. My opinion is that the KISS rule is the best option. Simply do not create a rate for students. If this is not widely acceptable, then have a rate, but make sure that we set a qualification for the rate that is acceptable. I would say that a full-time student at a post-secondary institution (proven with a student ID and student attestation) is good enough to establish a student membership. I really hope this will be clarified as a membership structure needs to be very clear and simple to be successful. We really don't need confusion on this topic. - Brian J. CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] an alternate proposal forNewNOG's membership structure
On 2011-01-05, at 09:40, Brian Johnson wrote: snip http://www.nanog.org/meetings/attending/wavingfee/studentreg.php doesn't indicate that they need to be full time, so I guess they just have to be a college or university student. Period. Yes? why only university? wazza matter with the younger set? i have worked with some bitchin' good 15 year olds that became senior geeks over the years. This is exactly the problem. We have to qualify what a student is We do? I suggested before that people could be considered students if they claim to be, and that we could defer any more stringent requirements (difficult as those are to specify, given the effectively global constituency) if it turns out we actually have a problem to solve. Given that (I believe) the vast majority of attendees are funded by their employers to come, do we really expect the widespread telling of lies? Otherwise, what's a university? What's a college? What's a school? (If you think these are easy questions, you're thinking too locally). If I have been enrolled at a Canadian University for ten years but haven't taken a course for five, I still have a student ID (or can get one). Do I qualify? Who gets to verify the veracity of student IDs from the UK, or from France, or from Egypt, or from Pakistan? How would they do it? Is it really worth the trouble? Joe ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
[Nanog-futures] NewNOG membership policy adopted
Based on the proposal sent last month and discussion on this list, the NewNOG Board has adopted a membership policy. As in the proposal, there are two components: a Bylaws amendment to establish a framework, and a board resolution to set the policy. The full text of both parts are appended below. The amendment text is unchanged from the proposal. It takes effect immediately, but will need to be ratified by the membership during the fall election. After discussion on the list, we changed one element of the proposed framework, to allow the member registration discount to be applied to the general early registration rate and only exclude its use from special rates (such as for students.) This change appeared to have broad consensus. We chose to go with this simple set of rules, and can adjust them as needed as we gain experience. As always, discussion on this list is encouraged. Over the next few days, we will establish procedures to become a member, and will announce them here. Thanks, Steve (for the Board) == Bylaws amendment, adopted by unanimous vote of the Board on January 4, 2011, effective immediately but subject to ratification by the membership: - Replace the current section 5 in its entirety with: 5. Membership 5.1 Membership Qualifications Membership in NewNOG is open to any individual with an interest in Internet operations, engineering, or research and who wishes to further education and knowledge sharing within the Internet operations community. Any individual may become a member of NewNOG by completing an application and payment of dues. 5.2 Membership Classes There shall be only one class of membership, with all the rights and privileges specified in these Bylaws. 5.3 Membership Dues The Board of Directors shall specify the cost of annual membership dues. The Board may establish discounts for members meeting certain criteria, or for members wishing to pay for more than one year in advance. 5.4 Rights and Benefits of Members Members in good standing shall be entitled to these privileges: * Vote in all NewNOG elections. * Run as a candidate for the Board of Directors * Serve on an administrative committee, as defined in section 9 * Other privileges as specified by the Board of Directors 5.5 Policies and Procedures The Board of Directors shall establish and publish policies and procedures for implementation of the membership program. == Membership Policies and Procedures, adopted by Board resolution Jan. 4, 2011: 1. Annual Dues 1.1 Standard rate The standard annual dues is $100. 1.2 Student discount Students enrolled in an undergraduate or graduate degree program at an accredited institution will receive a 50% discount for annual dues. Proof of enrollment is required. This may not be combined with any other discount. 1.3 Multi-year discount Individuals who prepay three or more years of membership in advance will receive a 10% discount. This may not be combined with any other discount. 2. Membership Terms 2.1 Start of membership The term of membership shall begin immediately upon receipt of the member's application and payment for dues. 2.2 Expiration of membership 2.2.1 New memberships For new members, the term of membership shall expire one year after the last day of the month during which the membership started, unless membership is renewed. 2.2.2 Continuing memberships For continuing members, the term of membership shall expire one year after the previous expiration date, unless membership is renewed. 2.3 Renewal A member may renew by submitting payment of the current dues amount before the expiration of the current membership term. Members who have prepaid for more than one year in advance shall be automatically renewed for the additional years prepaid. 3. Additional Benefits 3.1 Meeting discount Members in good standing will receive a $25 discount on registration fees for any conference operated by NewNOG. This discount may not be applied any to any special registration rates, such as for speakers, students, sponsors, or members of the press. == ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] an alternate proposal forNewNOG's membership structure
I'm so sick of this conversation. Why are we discussing this as if it should have any weight. Find me an organization that has a student membership without any qualifications and I'll show you exponentially more that have one. I also don't like being taken out of context. Please read the thread before posting on a single post. You'll see that I'm against this whole thing. Specific responses are in-line. On 2011-01-05, at 09:40, Brian Johnson wrote: snip http://www.nanog.org/meetings/attending/wavingfee/studentreg.php doesn't indicate that they need to be full time, so I guess they just have to be a college or university student. Period. Yes? why only university? wazza matter with the younger set? i have worked with some bitchin' good 15 year olds that became senior geeks over the years. This is exactly the problem. We have to qualify what a student is We do? I suggested before that people could be considered students if they claim to be, and that we could defer any more stringent requirements (difficult as those are to specify, given the effectively global constituency) if it turns out we actually have a problem to solve. Given that (I believe) the vast majority of attendees are funded by their employers to come, do we really expect the widespread telling of lies? You are confusing meeting attendance with membership. I doubt my employer will pay my membership dues. My case may be different. I like how you destroyed my statement before refuting it. I am actually in agreement that there may be no problem. But then why is this a discussion then. If student membership is important to you, explain why students are deserving of a discount on membership. Otherwise, what's a university? What's a college? What's a school? (If you think these are easy questions, you're thinking too locally). This was the point of my message. I said that it would suck to do this. Take off the blinders. If I have been enrolled at a Canadian University for ten years but haven't taken a course for five, I still have a student ID (or can get one). Do I qualify? I would hope the ID has a date on it, but this is exactly the point. I'm against even having the student membership with full membership rights. I was a student (still am, as we all are or should be) and would pay full dues to an organization if It was important to me to be a member. Who gets to verify the veracity of student IDs from the UK, or from France, or from Egypt, or from Pakistan? How would they do it? Is it really worth the trouble? Exactly. So say we offer student rates and it does become an issue. Who will we pay to resolve it? Where will that money come from? - Brian J. CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] an alternate proposal forNewNOG's membership structure
On 2011-01-05, at 11:10, Brian Johnson wrote: I also don't like being taken out of context. Please read the thread before posting on a single post. You'll see that I'm against this whole thing. Sure, but I'm not against student discounts (for whatever, membership, attendance). I'm just against over-specifying what student means. Joe ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] an alternate proposal forNewNOG's membership structure
On 1/5/11 8:07 AM, Joe Abley wrote: Who gets to verify the veracity of student IDs from the UK, or from France, or from Egypt, or from Pakistan? How would they do it? Is it really worth the trouble? Someone please explain to me how accepting students outside of North America as members directly benefits an organization that has a stated focus on North America? Yes, I understand that the Internet is global, as are a lot of topics and attendees of the conference and list members, but I don't see a benefit of global student membership. Of course, this seems to have become a moot point, as something has been adopted into the bylaws. -Sean ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] an alternate proposal for NewNOG's membership structure
--- ra...@psg.com wrote: From: Randy Bush ra...@psg.com http://www.nanog.org/meetings/attending/wavingfee/studentreg.php doesn't indicate that they need to be full time, so I guess they just have to be a college or university student. Period. Yes? why only university? wazza matter with the younger set? i have worked with some bitchin' good 15 year olds that became senior geeks over the years. I only repeated what I saw on the link. Trying to not toss too much confusion into the fray. I am just looking for a way to get younger new members into the org. They always have little money and no employer to pay for them. I knew some part time students that were doing CS while working to support their family and they wanted a way to show potential future employers they are working harder than the 'other guy' to bust into the industry and get a good job. I just hope NewNOG can support that. College is tough. It seems like we would want to get these folks in early and have them stick around throughout their careers. The money lost to the discount will come back into the org in the long run. scott ps. do the initial members get a cool cert showing us as OGs? :-) ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] an alternate proposal for NewNOG's membership structure
Ok, thanks for the clarification. scott --- s...@labrats.us wrote: From: Sean Figgins s...@labrats.us To: nanog-futures@nanog.org Subject: Re: [Nanog-futures] an alternate proposal for NewNOG's membership structure Date: Wed, 05 Jan 2011 13:12:35 -0700 On 1/5/11 11:21 AM, Scott Weeks wrote: I only repeated what I saw on the link. Trying to not toss too much confusion into the fray. I am just looking for a way to get younger new members into the org. They always have little money and no employer to pay for them. I knew some part time students that were doing CS while working to support their family and they wanted a way to show potential future employers they are working harder than the 'other guy' to bust into the industry and get a good job. I just hope NewNOG can support that. College is tough. It seems like we would want to get these folks in early and have them stick around throughout their careers. The money lost to the discount will come back into the org in the long run. But, students already get a discount at the conference, and do not get any further discounts, so the student membership is really just costing them money to show nothing. All membership gets you at this point is involvement in the organization, not the activity of NANOG. I think the point that is lost on many people is that NANOG will become an activity of NewNOG. It may be the ONLY activity, but being a member of NewNOG does not mean that you are actively participating in NANOG or network operations. It just means that you are interested in the operation of the NewNOG organization. ps. do the initial members get a cool cert showing us as OGs? :-) I don't think there are any perks like that at this point... We had discussed things such as membership cards, or membership numbers, but that does not seem to have been accepted. -Sean ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: NIST IPv6 document
Dear Jeff, In my opinion the real challenges already in IPv6 networks the following: SPAM and attacking over IPv6; DoS; track back hosts with privacy enhanced addresses. Do you have some methods in your mind to resolve ARP/ND overflow problem? I think limiting mac address per port on switches both efficient on IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should be implemented by the switch vendors But remember DHCP snooping et al. implemented in IPv4 after the first serious attacks...Make pressure on your switch vendors Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 5 Jan 2011, Jeff Wheeler wrote: On Tue, Jan 4, 2011 at 11:35 PM, Kevin Oberman ober...@es.net wrote: The PDF is available at: I notice that this document, in its nearly 200 pages, makes only casual mention of ARP/NDP table overflow attacks, which may be among the first real DoS challenges production IPv6 networks, and equipment vendors, have to resolve. Some platforms have far worse failure modes than others when subjected to such an attack, and information on this subject is not widely-available. Unless operators press their vendors for information, and more knobs, to deal with this problem, we may all be waiting for some group like Anonymous to take advantage of this vulnerability in IPv6 networks with large /64 subnets configured on LANs; at which point we may all find ourselves scrambling to request knobs, or worse, redesigning and renumbering our LANs. RFC5157 does not touch on this topic at all, and that is the sole reference I see in the NIST publication to scanning attacks. I continue to believe that a heck of a lot of folks are missing the boat on this issue, including some major equipment vendors. It has been pointed out to me that I should have been more vocal when IPv6 was still called IPng, but in 16 years, there has been nothing done about this problem other than water-cooler talk. I suspect that will continue to be the case until those of us who have configured our networks carefully are having a laugh at the networks who haven't. However, until that time, it's also been pointed out to me that customers will expect /64 LANs, and not offering it may put networks at a competitive disadvantage. Vendor solutions are needed before scanning IPv6 LANs becomes a popular way to inconvenience (at best) or disable (at worst) service providers and their customers. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: NIST IPv6 document
On Jan 5, 2011, at 1:15 PM, Jeff Wheeler wrote: I notice that this document, in its nearly 200 pages, makes only casual mention of ARP/NDP table overflow attacks, which may be among the first real DoS challenges production IPv6 networks, and equipmentvendors, have to resolve. They also only make small mention of DNS- and broadcast-hinted scanning, and none at all of routing-hinted scanning. It has been pointed out to me that I should have been more vocal when IPv6 was still called IPng, but in 16 years, there has been nothing done about this problem other than water-cooler talk. Likewise. I never in my wildest dreams thought that such a bag of hurt, with all the problems of IPv4 *plus* its own inherent problems - in *hex*, no less - would end up being adopted. I was sure that the adults would step in, at some point, and get things back on a more sensible footing. Obviously, I'm the biggest idiot on the Internet, and have only my own misplaced faith in the IAB/IETF process to blame, heh. The authors of the document also make only small mention of the dangers of extension header-driven DoS for infrastructure, but at least they mention it, which puts them ahead of most folks in this regard. They also fail to mention the dangers represented by the consonance of the English letters 'B', 'C', 'D', and 'E'. My guess it that billions of USD in outages, misconfigurations, and avoidable security incidents will result from verbal miscommunication of these letters, yet another reason why adopting a hexadecimal numbering scheme was foolish in the extreme. Ah, well, no use crying over spilt milk. The document itself is a good tutorial on IPv6, and it's great that the authors did indeed touch upon these security concerns, but the security aspect as a whole is seemingly deliberately understated, which does a disservice to the lay reader. One can only imagine that there were non-technical considerations which came into play. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Jan 5, 2011, at 4:39 PM, Dobbins, Roland wrote: They also only make small mention of DNS- and broadcast-hinted scanning, and none at all of routing-hinted scanning. I meant to include, ' . . . and the strain that this hinted scanning will place on the DNS and routing/switching infrastructure.' Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: FAA - ASDI servers
On Jan 4, 2011, at 11:07 PM, Christopher Morrow wrote: On Tue, Jan 4, 2011 at 10:50 PM, Menerick, John jmener...@netsuite.com wrote: Every joke has a bit of truth. For instance, until recently (last 10 years?), O'hare's traffic controllers relied upon vacuum tube technology to perform their job. yea, I was really referring to the ATC part of the FAA I suppose... I'm not sure it's still true, but every time I hear it come up in conversation (I bet owen delong would actually know...or rs) there is a bit of: Well, we could migrate to something NOT VT based, but that'd take 3+ years and ... we have other priorities and ... wash/rinse/repeat... On a serious note though: http://www.fly.faa.gov/ASDI/asdi.html (note this is the first hit in google searches for 'adsi server faa') seems to have all manner of information on it about the systems in question. They seem to mention VPN services, I suspect there isn't v6 access, I would have read the requirements doc, but they wanted to send it to me as a .doc file... uhm, this is the 21st century could we distribute this in some sort of cross-platform manner? like txt ? or pdf? (though I hesitate to suggest pdf, what with the adobe pwnage consistently ongoing these days) There is a federal directive that has been in place for a number of years that requires IPV6 support for all new IT contracts/systems and also a directive to all federal agencies to support IPV6 by 2008 (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) Tom
Re: NIST IPv6 document
On 01/05/2011 10:39 AM, Dobbins, Roland wrote: The document itself is a good tutorial on IPv6, and it's great that the authors did indeed touch upon these security concerns, but the security aspect as a whole is seemingly deliberately understated, which does a disservice to the lay reader. One can only imagine that there were non-technical considerations which came into play. That almost sounds like a conspiracy theory, let me know when it shows up on Wikileaks. :-) I think it's better to show what is broken and let vendors fix it, then to look the other way. The only people I know actively and openly working on creating tests to find and report bugs in IPv6 protocols and software is the THC-IPV6-project by van Hauser. Here is an old presentation from 2005 from him: http://media.ccc.de/browse/congress/2005/22C3-772-en-attacking_ipv6.html http://events.ccc.de/congress/2005/fahrplan/attachments/642-vh_thcipv6_attackccc05presentation.pdf Most is still possible and not fixed to this date. And his site: http://www.thc.org/thc-ipv6 He did a new presentation at 27c3 in december 2010: http://events.ccc.de/congress/2010/Fahrplan/events/3957.en.html A video and slides should show up on the list soon: http://media.ccc.de/tags/27c3.html (because of audio transcoding issues some videos are not online right now, if you ask me nicely I could mail a link for the video from before they took it down) Have a nice day, Leen Besselink.
Re: FAA - ASDI servers
TR Shaw ts...@oitc.com writes: There is a federal directive that has been in place for a number of years that requires IPV6 support for all new IT contracts/systems and also a directive to all federal agencies to support IPV6 by 2008 (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) And conveniently it's even getting more traction than GOSIP did. I think there have been some federal directives to balance the budget too. Point being that a PDF of such a directive is worth the paper it is written on if people are inclined to just figure out a way around it. (for those who are lucky or young enough to not remember: http://en.wikipedia.org/wiki/GOSIP ) -r
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 5:34 AM, Leen Besselink l...@consolejunkie.net wrote: He did a new presentation at 27c3 in december 2010: http://events.ccc.de/congress/2010/Fahrplan/events/3957.en.html A video and slides should show up on the list soon: http://media.ccc.de/tags/27c3.html (because of audio transcoding issues some videos are not online right now, if you ask me nicely I could mail a link for the video from before they took it down) That talk is available on Youtube by the official account http://www.youtube.com/watch?v=c7hq2q4jQYw
Re: online backup software vendor
I highly recommend looking at Crashplan Pro. We use it for some of our customers and it works great, and the pricing is very reasonable. On Jan 4, 2011, at 9:02 PM, Richard Zheng wrote: Hi, We are looking at providing backup services for our customers. It should have software running on our servers with SAN attached to it and client software running on windows or mac. Anyone knows some good vendors? Thanks! Richard
Re: online backup software vendor
The original poster is looking for software that can be hosted locally, which Crashplan is not as far as I can tell. I am also looking for something that can be hosted locally. The only one we have been able to find is Vembu StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I would highly recommend *not* looking at them. I had not heard of the Commvault solution. We'll have to look into that. I also be grateful for any other options that people are using. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - I highly recommend looking at Crashplan Pro. We use it for some of our customers and it works great, and the pricing is very reasonable. On Jan 4, 2011, at 9:02 PM, Richard Zheng wrote: Hi, We are looking at providing backup services for our customers. It should have software running on our servers with SAN attached to it and client software running on windows or mac. Anyone knows some good vendors? Thanks! Richard
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 3:31 AM, Mohacsi Janos moha...@niif.hu wrote: Do you have some methods in your mind to resolve ARP/ND overflow problem? I think limiting mac address per port on switches both efficient on IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should be implemented by the switch vendors But remember DHCP snooping et al. implemented in IPv4 after the first serious attacks...Make pressure on your switch vendors Equipment vendors, and most operators, seem to be silent on this issue, not wishing to admit it is a serious problem, which would seem to be a required step before addressing it. Without more knobs on switches or routers, I believe there are only two possible solutions for production networks today: 1) do not configure /64 LANs, and instead, configure smaller subnets which will reduce the impact of scanning attacks This is not desirable, as customers may be driven to expect a /64, or even believe it is necessary for proper functioning. I brought this up with a colleague recently, who simply pointed to the RFC and said, that's the way you have to do it. Unfortunately, configuring the network the way the standard says, and accepting the potential DoS consequences, will likely be less acceptable to customers than not offering them /64 LAN subnets. This is a foolish position and will not last long once reality sets in, unless vendors provide more knobs. 2) use link-local addressing on LANs, and static addressing to end hosts. This prevents a subset of attacks originated from the Internet, by making it impossible for NDP to be initiated by scanning activity; but again, is not what customers will expect. It may have operational disadvantages with broken user-space software, is not easy for customers to configure, and does not permit easy porting of addresses among host machines. It requires much greater configuration effort, is likely not possible by way of DHCP. It also does not solve NDP table overflow attacks initiated by a compromised host on the LAN, which makes it a half-way solution. The knobs/features required to somewhat-mitigate the impact of an NDP table overflow attack are, at minimum: * keep NDP/ARP entry alive based on normal traffic flow, do not expire a host that is exchanging traffic + this is not the case with some major platforms, it surprised me to learn who does not do this + may require data plane changes on some boxes to inform control plane of on-going traffic from active addresses * have configurable per-interface limits for NDP/ARP resource consumption, to prevent attack on one interface/LAN from impacting all interfaces on a router + basically no one has this capability + typically requires only control plane modifications * have configurable minimum per-interface NDP/ARP resource reservation + typically requires only control plane modifications * have per-interface policer for NDP/ARP traffic to prevent control plane from becoming overwhelmed + because huge subnets may increase the frequency of scanning attacks, and breaking one interface by reaching a policer limit is much better than breaking the whole box if it runs out of CPU, or breaking NDP/ARP function on the whole box if whole-box policer is reached * learn new ARP/NDP entry when new transit traffic comes from a host on the LAN + even if NDP function is impared on the LAN due to on-going scan attack + again, per-interface limitations must be honored to protect whole box from breaking from one misconfigured / malicious LAN host * have sane defaults for all and allow all to be modified as-needed I am sure we can all agree that, as IPv6 deployment increases, many unimagined security issues may appear and be dealt with. This is one that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used, and yet, vendors are not doing anything about it. If customers don't express this concern to them, they won't do anything about it until it becomes a popular DoS attack. In addition, if you design your network around /64 LANs, and especially if you take misguided security-by-obscurity advice and randomize your host addresses so they can't be found in a practical time by scanning, you may have a very difficult time if the ultimate solution to this must be to change the typical subnet size from /64 to something that can fit within a practical NDP/ARP table. Deploying /64 networks because customers demand it and your competitors are doing it is understandable. Doing it because it's the standard is very stupid. Anyone doing that on, for example, SONET interfaces or point-to-point Ethernet VLANs in their infrastructure, is making a bad mistake. Doing it toward CE routers, the sort that have an IPv4 /30, is even more foolish; and many major ISPs already know this and are using small subnets such as /126 or /124. If you are still reading, but do not have any idea what I'm talking about, ask yourself these
Re: NIST IPv6 document
On Jan 5, 2011, at 7:21 PM, Jeff Wheeler wrote: please explain why this is in any way better than operating the same LAN with a subnet similar in size to its existing IPv4 subnets, e.g. a /120. Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space is, I know, and reject that argument out of hand) and b) it turns the routers/switches into sinkholes. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: online backup software vendor
On Wed, Jan 5, 2011 at 1:20 PM, Randy Carpenter rcar...@network1.netwrote: The original poster is looking for software that can be hosted locally, which Crashplan is not as far as I can tell. I am also looking for something that can be hosted locally. The only one we have been able to find is Vembu StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I would highly recommend *not* looking at them. I had not heard of the Commvault solution. We'll have to look into that. I'm using i365 eVault (www.i365.com) which is an locally hosted solution, with the usual bell and whistles (deduplication, asynchronous mirroring of the storage pool, agents for Exchange/SQL/Oracle/Linux/VMware etc.) and priced right. Did not use Commvault or StoreGrid so can't really compare, but never had any problem with i365! Cheers, ]\/[arco -- I'm Winston Wolf, I solve problems.
RE: online backup software vendor
Asigra? http://www.asigra.com/ Regards, Neil -Original Message- From: Marco Matarazzo [mailto:marm...@gmail.com] Sent: 05 January 2011 12:37 To: Randy Carpenter Cc: nanog@nanog.org Subject: Re: online backup software vendor On Wed, Jan 5, 2011 at 1:20 PM, Randy Carpenter rcar...@network1.netwrote: The original poster is looking for software that can be hosted locally, which Crashplan is not as far as I can tell. I am also looking for something that can be hosted locally. The only one we have been able to find is Vembu StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I would highly recommend *not* looking at them. I had not heard of the Commvault solution. We'll have to look into that. I'm using i365 eVault (www.i365.com) which is an locally hosted solution, with the usual bell and whistles (deduplication, asynchronous mirroring of the storage pool, agents for Exchange/SQL/Oracle/Linux/VMware etc.) and priced right. Did not use Commvault or StoreGrid so can't really compare, but never had any problem with i365! Cheers, ]\/[arco -- I'm Winston Wolf, I solve problems.
Re: online backup software vendor
Absolutely it can be hosted locally, we run the server software in our data center and our customers are clients who connect to it for backup. In fact, the server software is free to download and install. Code42, the makers, also run their own hosted version, which you may be seeing. Make sure you're looking at Crashplan PRO, and not just Crashplan. We considered Vembu early on as well, but opted for Crashplan instead. It works quite well - the main downside against some of the others is it doesn't support application level backup - it's purely filesystem based. Thus, you can't do things like backup individual Exchange accounts or SQL databases, which some people want. On Jan 5, 2011, at 7:20 AM, Randy Carpenter wrote: The original poster is looking for software that can be hosted locally, which Crashplan is not as far as I can tell. I am also looking for something that can be hosted locally. The only one we have been able to find is Vembu StoreGrid. Our experience with Vembu has ranged from abysmal to horrific. I would highly recommend *not* looking at them. I had not heard of the Commvault solution. We'll have to look into that. I also be grateful for any other options that people are using. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - I highly recommend looking at Crashplan Pro. We use it for some of our customers and it works great, and the pricing is very reasonable. On Jan 4, 2011, at 9:02 PM, Richard Zheng wrote: Hi, We are looking at providing backup services for our customers. It should have software running on our servers with SAN attached to it and client software running on windows or mac. Anyone knows some good vendors? Thanks! Richard
RE: FAA - ASDI servers
Note that the NIST IPv6 document Kevin pointed to, in the acknowledgements section, includes the following individual who assisted: Trung Nguyen, FAA Joe From: Ryan Finnesey ryan.finne...@harrierinvestments.com To: nanog@nanog.org Date: 01/04/2011 10:25 PM Subject: RE: FAA - ASDI servers Is anyone on the list from the FAA? I am trying to find out if we can connect to the ASDI servers via IPv6. Cheers Ryan
Re: FAA - ASDI servers
On Wed, Jan 05, 2011 at 06:36:25AM -0500, Robert E. Seastrom wrote: TR Shaw ts...@oitc.com writes: There is a federal directive that has been in place for a number of years that requires IPV6 support for all new IT contracts/systems and also a directive to all federal agencies to support IPV6 by 2008 (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) And conveniently it's even getting more traction than GOSIP did. I think there have been some federal directives to balance the budget too. Point being that a PDF of such a directive is worth the paper it is written on if people are inclined to just figure out a way around it. (for those who are lucky or young enough to not remember: http://en.wikipedia.org/wiki/GOSIP ) Bad cess to you for that! I thought I had recycled those neurons, but it turns out I hadn't. I suppose that cautionary tales are necessary, and GOSIP certainly is one. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: NIST IPv6 document
On 5 jan 2011, at 13:21, Jeff Wheeler wrote: customers may be driven to expect a /64, or even believe it is necessary for proper functioning. RFC 3513 says: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Nobody has been able or willing to tell why that's in there, though. All the same, beware of the anycast addresses if you want to use a smaller block for point-to-point and for LANs, you break stateless autoconfig and very likely terminally confuse DHCPv6 if your prefix length isn't /64. This is one that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive. A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. and yet, vendors are not doing anything about it. Then don't give them your business. And maybe a nice demonstration on stage at a NANOG meeting will help a bit? In addition, if you design your network around /64 LANs, and especially if you take misguided security-by-obscurity advice and randomize your host addresses so they can't be found in a practical time by scanning, you may have a very difficult time if the ultimate solution to this must be to change the typical subnet size from /64 to something that can fit within a practical NDP/ARP table. Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away.
RE: Experiences with Comcast Ethernet
This is what we worry about as well. Right now, when the complaints start coming in, we can usually trace the problem to a comcast - level3 - qwest issue. Our big concern is we start seeing over subscription on the nodes (we have dealt with this in the past) and our problems start all over again. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.eb...@crlmed.com www.consultingradiologists.com -Original Message- From: Bret Clark [mailto:bcl...@spectraaccess.com] Sent: Tuesday, January 04, 2011 7:40 PM To: nanog@nanog.org Subject: Re: Experiences with Comcast Ethernet On Tue, Jan 4, 2011 at 1:05 PM, Dylan Ebnerdylan.eb...@crlmed.com wrote: My company has about 2 dozen Comcast business cable accounts at satellite offices around the Midwest. We are looking at adding an additional ISP to the mix and we are thinking of purchasing an Ethernet circuit from Comcast in an attempt to increase performance on those connections by keeping all the traffic within Comcast's network. Comcast, of course, has assured us this will result in noticeable speed increases for those accounts. I am more weary. Does anyone have any experience with Comcast's ethernet offerings? How reliable are they? Do Comcast cable connections see a significant performance improvement? Dylan Ebner, Network Engineer It will only help if the performance issues are related to the Comcast Internet peering connections, otherwise you'll see no difference if the issues are related to congestion occurring on the coax connections from the optical nodes that services each coax feed through neighborhoods and business. This is simple over-utilization that (at least in our neck of the woods) is becoming more and more a problem as Comcast saturates there networks with too many connections...there is only so much bandwidth a coax line can handle! I suspect your performance issues are related to the latter. Bret
Re: NIST IPv6 document
On 1/5/2011 6:29 AM, Dobbins, Roland wrote: Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space is, I know, and reject that argument out of hand) and b) it turns the routers/switches into sinkholes. Except someone was kind enough to develop a protocol that requires /64 to work. So then there is the SLAAC question. When might it be used? With routers, I usually don't use SLAAC. The exception is end user networks, which makes using SLAAC + DHCPv6-PD extremely dangerous for my edge routers. DHCPv6 IA_TA + DHCPv6-PD would be more sane, predictable, and filterable (and support longer than /64) thought my current edge layout can't support this (darn legacy IOS). I would love a dynamic renumbering scheme for routers, but until all routing protocols (especially iBGP) support shifting from one prefix to the next without a problem, it's a lost cause and manual renumbering is still required. Things like abstracting the router id from the transport protocol would be nice. I could be wrong, but I think ISIS is about it for protocols that won't complain. All that said, routers should be /126 or similar for links, with special circumstances and layouts for customer edge. For server subnets, I actually prefer leaving it /64 and using SLAAC with token assignments. This is easily mitigated with ACLs to filter any packets that don't fall within the range I generally use for the tokens, with localized exceptions for non-token devices which haven't been fully initialized yet (ie, stay behind stateful firewall until I've changed my IP to prefix::0-2FF). I haven't tried it, but I highly suspect it would fail, but it would be nice to use SLAAC with longer than /64. Jack
IRSCP
I was curious if anyone has heard off or is playing around with Intelligent Route Service Control Point? Looks like there are some trials going on and it has potential to centralize routing descsions as well as a DDOS mitigation tool, thoughts? harbor235 ;}
vmware recover a 4.0 boot with a 4.1 cd
borked vmware boot, reset says no opsys found. it's a 4.0 system. can i do recovery (saving vmfs) using 4.1 cd, or must i use 4.0? randy
Re: vmware recover a 4.0 boot with a 4.1 cd
Randy Bush (randy) writes: borked vmware boot, reset says no opsys found. it's a 4.0 system. can i do recovery (saving vmfs) using 4.1 cd, or must i use 4.0? Yes, it will work for accessing the vmfs, at the very least. Phil
Re: AltDB?
[moved to nanog as it seems a far more appropriate forum than cisco-nsp] On Wed, 5 Jan 2011, Jose Madrid wrote: Anyone here use AltDB? It seems their servers have been down for two days. I have emailed their admin alias but have gotten nothing. Anyone? whois -h whois.altdb.net 199.48.252.0 [Querying whois.altdb.net] [Unable to connect to remote host] Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? I'm guessing if whatever the problem is with altdb isn't fixed soon, those who use it as their IRR will need to re-publish all their objects in another IRR DB and have any transit providers who build filters based on IRR data update their profiles to use object data from the IRR DB to which they moved their records. I'd been thinking about moving from altdb to ARIN's but hadn't had sufficient motivation. www.altdb.net is reachable, but the whois server is not. Even altdb queries run from http://www.altdb.net/ fail. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: online backup software vendor
Does anyone have any comments on any of these solutions being easily managed for end users? We need something that is easy for the customers to install and configure, and is centrally managed. It would also be very nice if it could be fully branded (the one thing that Vembu does well) thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Wed, Jan 5, 2011 at 5:40 AM, Neil Robst neil.ro...@ioko.com wrote: Asigra? http://www.asigra.com/ Regards, Neil I have hands on experience with Asigra and would recommend it. JP
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum iljit...@muada.com wrote: that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive. It appears you want to have a semantic argument. I could grant that, and every point in my message would still stand. However, given that the necessary knobs to protect the network with /64 LANs do not exist on any platform today, vendors are not talking about whether or not they may in the future, and that no implementation with /64 LANs connected to the Internet, or any other routed network which may have malicious or compromised hosts, design flaw is correct. This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet. You seem to think the issue is generating NDP NS. While that is a part of the problem, even if a router can generate NS at an unlimited rate (say, by implementing it in hardware) it cannot store an unlimited number of entries. The failure modes of routers that have a full ARP or NDP table obviously vary, but it is never a good thing. In addition, the high-rate NS inquiries will be received by some or all of the hosts on the LAN, consuming their resources and potentially congesting the LAN. Further, if the router's NDP implementation depends on tracking the status of incomplete on-going inquiries, the available resource for this can very easily be used up, preventing the router from learning about new neighbors (or worse.) If it does not depend on that, and blindly learns any entry heard from the LAN, then its NDP table can be totally filled by any compromised / malicious host on the LAN, again, breaking the router. Either way is bad. This is a fundamentally different and much larger problem than those experienced with ARP precisely because the typical subnet size is now, quite literally, seventy-quadrillion times as large as the typical IPv4 subnet. On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum iljit...@muada.com wrote: A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. It would certainly be nice to have a stateful firewall on every single LAN connection. Were there high-speed, stateful firewalls in 1994? Perhaps the IPng folks had this solution in mind, but left it out of the standards process. No doubt they all own stock in SonicWall and are eagerly awaiting the day when Anonymous takes down a major ISP every day with a simple attack that has been known to exist, but not addressed, for many years. You must also realize that the stateful firewall has the same problems as the router. It must include a list of allocated IPv6 addresses on each subnet in order to be able to ignore other traffic. While this can certainly be accomplished, it would be much easier to simply list those addresses in the router, which would avoid the expense of any product typically called a stateful firewall. In either case, you are now maintaining a list of valid addresses for every subnet on the router, and disabling NDP for any other addresses. I agree with you, this knob should be offered by vendors in addition to my list of possible vendor solutions. On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum iljit...@muada.com wrote: Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away. I do not conceptually disagree with sparse subnets. With the equipment limitations of today, they are a plan to fail. Let's hope that all vendors catch up to this before malicious people/groups. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
RE: online backup software vendor
Asigra is a great product, however branding isn’t possible from what I know of the solution. We use Asigra through a partner, and when well managed it is a GREAT solution, however it can easily spin out of control if someone doesn't keep on top of it. Randy if you are looking for a little more hands on information with Asigra, feel free to contact me off list and I can arrange a better demo. -Original Message- From: Randy Carpenter [mailto:rcar...@network1.net] Sent: Wednesday, January 05, 2011 9:50 AM To: jake pollmann Cc: Neil Robst; nanog@nanog.org Subject: Re: online backup software vendor Does anyone have any comments on any of these solutions being easily managed for end users? We need something that is easy for the customers to install and configure, and is centrally managed. It would also be very nice if it could be fully branded (the one thing that Vembu does well) thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Wed, Jan 5, 2011 at 5:40 AM, Neil Robst neil.ro...@ioko.com wrote: Asigra? http://www.asigra.com/ Regards, Neil I have hands on experience with Asigra and would recommend it. JP
Re: online backup software vendor
We use Ahsay online backup server (http://www.ahsay.com/jsp/en/home/index.jsp). I've been very happy with it. - Original Message - From: Richard Zheng rzh...@gmail.com To: nanog@nanog.org Sent: Tuesday, January 4, 2011 9:02:23 PM Subject: online backup software vendor Hi, We are looking at providing backup services for our customers. It should have software running on our servers with SAN attached to it and client software running on windows or mac. Anyone knows some good vendors? Thanks! Richard -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760
Re: NIST IPv6 document
On 1/5/11 8:49 AM, Jeff Wheeler wrote: On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum iljit...@muada.com wrote: that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive. It appears you want to have a semantic argument. I could grant that, and every point in my message would still stand. However, given that the necessary knobs to protect the network with /64 LANs do not exist on any platform today, vendors are not talking about whether or not they may in the future, and that no implementation with /64 LANs connected to the Internet, or any other routed network which may have malicious or compromised hosts, design flaw is correct. This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet. no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet. You seem to think the issue is generating NDP NS. While that is a part of the problem, even if a router can generate NS at an unlimited rate (say, by implementing it in hardware) it cannot store an unlimited number of entries. The failure modes of routers that have a full ARP or NDP table obviously vary, but it is never a good thing. In addition, the high-rate NS inquiries will be received by some or all of the hosts on the LAN, consuming their resources and potentially congesting the LAN. Further, if the router's NDP implementation depends on tracking the status of incomplete on-going inquiries, the available resource for this can very easily be used up, preventing the router from learning about new neighbors (or worse.) If it does not depend on that, and blindly learns any entry heard from the LAN, then its NDP table can be totally filled by any compromised / malicious host on the LAN, again, breaking the router. Either way is bad. This is a fundamentally different and much larger problem than those experienced with ARP precisely because the typical subnet size is now, quite literally, seventy-quadrillion times as large as the typical IPv4 subnet. On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum iljit...@muada.com wrote: A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use. It would certainly be nice to have a stateful firewall on every single LAN connection. Were there high-speed, stateful firewalls in 1994? Perhaps the IPng folks had this solution in mind, but left it out of the standards process. No doubt they all own stock in SonicWall and are eagerly awaiting the day when Anonymous takes down a major ISP every day with a simple attack that has been known to exist, but not addressed, for many years. You must also realize that the stateful firewall has the same problems as the router. It must include a list of allocated IPv6 addresses on each subnet in order to be able to ignore other traffic. While this can certainly be accomplished, it would be much easier to simply list those addresses in the router, which would avoid the expense of any product typically called a stateful firewall. In either case, you are now maintaining a list of valid addresses for every subnet on the router, and disabling NDP for any other addresses. I agree with you, this knob should be offered by vendors in addition to my list of possible vendor solutions. On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum iljit...@muada.com wrote: Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away. I do not conceptually disagree with sparse subnets. With the equipment limitations of today, they are a plan to fail. Let's hope that all vendors catch up to this before malicious people/groups.
Re: AltDB?
On Wed, Jan 5, 2011 at 11:26 AM, Jon Lewis jle...@lewis.org wrote: Anyone here use AltDB? It seems their servers have been down for two days. Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? I'm guessing Since Level3 updates their prefix-lists at least daily, and integrates new ALTDB updates at least daily, and the ALTDB has been down for over a day, obviously it will not affect your Level3 prefix-lists in the near-term. If Level3 decided to stop honoring ALTDB objects, say, because ALTDB was never fixed, I imagine you would find it necessary to re-publish your objects or Level3 would stop honoring your routes. I'd been thinking about moving from altdb to ARIN's but hadn't had sufficient motivation. I emailed ARIN yesterday to ask if their IRR database has any authentication support (other than mail-from) yet. I haven't seen any reply from ARIN yet, but my guess is they still have no useful authentication mechanism. I would rather depend on an IRR database that can't process updates for a few days per year, than use one where a malicious party could alter or erase all of my objects at any time. I would like to note that RADB had route6: support in about 2004 or so, if my memory serves me; while the ARIN database did not accept route6 objects until about a year ago. So it is not exactly a high priority for ARIN. Note also that Level3 has an IRR database, so you could use theirs if you want to. I don't prefer to use a transit provider database if I can use a neutral one, but sometimes I would rather not pay the (entirely reasonable) fee for the MERIT RADB. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: AltDB?
On Jan 5, 2011, at 9:26 AM, Jon Lewis wrote: [snip] Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? Yes, Level 3 will continue to use the last data mirrored and archived. New filters are not pushed daily, they are only pushed when things change. Archives are here in case people want to know what the latest was: ftp://rr.level3.net/pub/rr/archive.mirror-data/ regards
Re: reporting physical plant damage to ATT?
On Nov 25, 2010, at 2:11 PM, Kevin Oberman wrote: Have you tried 611 (from an ATT land-line phone)? Many people don't have one. I haven't had one for over 12 years now, nor have any of my employers for the last 8 years. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: AltDB?
On 05/01/2011 17:09, Craig Pierantozzi wrote: On Jan 5, 2011, at 9:26 AM, Jon Lewis wrote: [snip] Can anyone from Level3 say how this will impact customer BGP filters. Will L3 keep working with the last data sync they got from altdb? Yes, Level 3 will continue to use the last data mirrored and archived. New filters are not pushed daily, they are only pushed when things change. Archives are here in case people want to know what the latest was: ftp://rr.level3.net/pub/rr/archive.mirror-data/ regards So has anyone had any contact from ALTDB as to what's going on? Thanks! --J
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 12:04 PM, Joel Jaeggli joe...@bogus.com wrote: no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet. These conditions can only be triggered by malicious hosts on the LAN. With IPv6, it can be triggered by scanning attacks originated from the Internet. No misconfiguration or compromised machine on your network is necessary. This is why it is a fundamentally different, and much larger, problem. Since you seem confused about the basic nature of this issue, I will explain it for you in more detail: IPv4) I can scan your v4 subnet, let's say it's a /24, and your router might send 250 ARP requests and may even add 250 incomplete entries to its ARP table. This is not a disaster for that LAN, or any others. No big deal. I can also intentionally send a large amount of traffic to unused v4 IPs on the LAN, which will be handled as unknown-unicast and sent to all hosts on the LAN via broadcasting, but many boxes already have knobs for this, as do many switches. Not good, but also does not affect any other interfaces on the router. IPv6) I can scan your v6 /64 subnet, and your router will have to send out NDP NS for every host I scan. If it requires incomplete entries in its table, I will use them all up, and NDP learning will be broken. Typically, this breaks not just on that interface, but on the entire router. This is much worse than the v4/ARP sitation. I trust you will understand the depth of this problem once you realize that no device has enough memory to prevent these attacks without knobs that make various compromises available via configuration. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: NIST IPv6 document
Jeff Wheeler (jsw) writes: IPv4) [...] Not good, but also does not affect any other interfaces on the router. You're assuming that all routing devices have per-interface ARP tables. IPv6) Typically, this breaks not just on that interface, but on the entire router. This is much worse than the v4/ARP sitation. Inverse assumption here. Doesn't change much to the case scenario you've put forward as a cause to the problem, but still wanted to point it out. Cheers, Phil
RE: AltDB?
So has anyone had any contact from ALTDB as to what's going on? Thanks! --J I just got off the phone with Steve Rubin. He restarted it 45 minutes ago and it's back up. Regards, Randy
Re: NIST IPv6 document
On 1/5/2011 11:19 AM, Jeff Wheeler wrote: IPv6) I can scan your v6 /64 subnet, and your router will have to send out NDP NS for every host I scan. If it requires incomplete entries in its table, I will use them all up, and NDP learning will be broken. Typically, this breaks not just on that interface, but on the entire router. This is much worse than the v4/ARP sitation. I haven't checked of late for v6, but I'd expect the same NDP security we have for ARP these days, which reduces the need to even send unsolicited ND requests. In this day and age, sending unsolicited neighbor requests from a router seems terribly broken. Even with SLAAC, one could quickly design a model that doesn't require unsolicited ND from the router to find the remove computer. This could possibly utilize DAD checks or even await the first packet from the node (similar to how we fill our MAC forwarding tables in switches, and not all switches will broadcast when a MAC is unknown). Jack
Re: NIST IPv6 document
IPv6) I can scan your v6 /64 subnet, and your router will have to send out NDP NS for every host I scan. If it requires incomplete entries in its table, I will use them all up, and NDP learning will be broken. Typically, this breaks not just on that interface, but on the entire router. This is much worse than the v4/ARP sitation. I'm guessing you're referring to this paragraph of RFC 4861: When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces, this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address. http://tools.ietf.org/html/rfc4861#section-7.2.2 It's worth noting that nothing in this paragraph is normative (there's no RFC 2119 language), so implementations are free to ignore it. I haven't read the NIST document, but it wouldn't conflict with the RFC if they recommended ignoring this paragraph and just relying on the ND cache they already have when a packet arrives. --Richard
Re: AltDB?
On 2011-01-05, at 12:31, Jared Mauch wrote: 2) If you DEPEND on something for your business, it may just be worth it to: a) pay RADB who operates professionally b) use your ISP provided IRR (eg: NTT, level3, savvis, etc) I generally recommend that people use the RIPE database, regardless of location. The main reason for that used to be that they supported IPv6 policy attributes before anybody else did, but that's quite possibly no longer a useful discriminator. If you ever have ambitions to announce a route to a peer in Europe, having objects in the RIPE db can also help avoid annoyance. Joe
Re: reporting physical plant damage to ATT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2011 09:11 AM, Jo Rhett wrote: On Nov 25, 2010, at 2:11 PM, Kevin Oberman wrote: Have you tried 611 (from an ATT land-line phone)? Many people don't have one. I haven't had one for over 12 years now, nor have any of my employers for the last 8 years. They have an 877 number that routes to the same people. I was at a client and they were having some sort of telco emergency and obtained the number as part of the resolution process. Here it is: from http://www.att.com/gen/general?pid=1603 Repair Service 1-866-346-1168 or 611 within state 24 hours a day, 7 days a week It's amazing how many people don't know about 611. It's the fastest way to reach clued/capable of paging clued people. - -- Charles N Wyble (char...@knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNJK1KAAoJEMvvG/TyLEAtWVgP/3jB6bEu3s7whO1ONHDedJYr NVurhbgNu3EZkbzffXb/NLT2OhfIZNPwAYD0P1H7D8KbZRo3fd+OX8f1q2ys/1G4 /3WV2gEyny9K7GJ8xnK6o7oFnaKc0SXVEk/0T4rHZhAsm5Gpjym42ecAbIf40CZr 63TovwrYUOambFY05Do6UWnkzFGghESwWjQyZKJ3YcQ9upwUBgRQ/uYnGL7MqPDR sr31DjzvtX7woAS1ZC4yH7s4QJ+YnURkgcEfMsDNOGqlak47T53JEgE/YaUp8oQp kxw5ppijLN2xmjQMGfzErDuGVlGpGxJq6bWDNLSQnEXZ3MK56DdnhjUfPYKFiBtj qr/C9GW+16uSlcwIFSvl6EOxoiLkqnQ4QW5py2+D0o9P2K0BMkVluNu+9N0ledp7 9NJSV6WaJEJQnOn6AWEBrpwQPeys5VJksac3eAmqB8ftFus8JeYKGiJSlwSAqP0S EVWn3Z/sSVwcIF1rEzR0bR8ha7AX6eZctcXV1cXETsATwf4nKmr9hiq2qB1nW6bU yAJIluvrBoHxZ8ZkbbtHN5VC+E/mdLJiLcs77+e+0kweh+AFzAQ5/rwNl9iHLGjz ZO6y9xp9novJEHrVWIyYw/Dy7WVlw8o+od3S5bmfjEe3+3hIPCeOfOd1CuevVNaX gEKSu2SK41HRhBxeg+OL =oIB0 -END PGP SIGNATURE-
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld regna...@nsrc.org wrote: Jeff Wheeler (jsw) writes: Not good, but also does not affect any other interfaces on the router. You're assuming that all routing devices have per-interface ARP tables. No, Phil, I am assuming that the routing device has a larger ARP table than 250 entries. To be more correct, I am assuming that the routing device has a large enough ARP table that any one subnet could go from 0 ARP entries to 100% ARP entries without using up all the remaining ARP resources on the box. This is usually true. Further, routing devices usually have enough ARP table space that every subnet attached to them could be 100% full of active ARP entries without using up all the ARP resources. This is also often true. To give some figures, a Cisco 3750 pizza box layer-3 switch has room for several thousand ARP entries, and I have several with 3000 - 5000 active ARPs. Most people probably do not have more than a /20 worth of subnets for ARPing to a pizza box switch like this, but it does basically work. As we all know, a /64 is a lot more than a few thousand possible addresses. It is more addresses than anyone can store in memory, so state information for incomplete can't be tracked in software without creating problems there. Being fully stateless for new neighbor learning is possible and desirable, but a malicious host on the LAN can badly impact the router. This is why per-interface knobs are badly needed. The largest current routing devices have room for about 100,000 ARP/NDP entries, which can be used up in a fraction of a second with a gigabit of malicious traffic flow. What happens after that is the problem, and we need to tell our vendors what knobs we want so we can choose our own failure mode and limit damage to one interface/LAN. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: NIST IPv6 document
Jeff Wheeler (jsw) writes: are badly needed. The largest current routing devices have room for about 100,000 ARP/NDP entries, which can be used up in a fraction of a second with a gigabit of malicious traffic flow. What happens after that is the problem, and we need to tell our vendors what knobs we want so we can choose our own failure mode and limit damage to one interface/LAN. Well there are *some* knobs: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1369018 Not very smart, as it just controls how fast you run out of entries. I haven't read all entries in this thread yet, but I wonder if http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 has been mentioned ? Seems also that this topic has been brought up here a year ago give or take a couple of weeks: http://www.mail-archive.com/nanog@nanog.org/msg18841.html Cheers, Phil
Re: NIST IPv6 document
IPv4) I can scan your v4 subnet, let's say it's a /24, and your router might send 250 ARP requests and may even add 250 incomplete entries to its ARP table. This is not a disaster for that LAN, or any others. No big deal. I can also intentionally send a large amount of traffic to unused v4 IPs on the LAN, which will be handled as unknown-unicast and sent to all hosts on the LAN via broadcasting, but many boxes already have knobs for this, as do many switches. Not good, but also does not affect any other interfaces on the router. IPv6) I can scan your v6 /64 subnet, and your router will have to send out NDP NS for every host I scan. If it requires incomplete entries in its table, I will use them all up, and NDP learning will be broken. Typically, this breaks not just on that interface, but on the entire router. This is much worse than the v4/ARP sitation. Many would argue that the version of IP is irrelevant, if you are permitting external hosts the ability to scan your internal network in an unrestricted fashion (no stateful filtering or rate limiting) you have already lost, you just might not know it yet. Even granting that, for the sake of argument - it seems like it would not be hard for $vendor to have some sort of emergency garbage collection routines within their NDP implementations ... ? /TJ
Re: NIST IPv6 document
All the same, beware of the anycast addresses if you want to use a smaller block for point-to-point and for LANs, you break stateless autoconfig and very likely terminally confuse DHCPv6 if your prefix length isn't /64. Breaking stateless autoconfig such that it *cannot* ever work, on my router point-to-point links, is a *feature*. Not a problem. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 1:02 PM, TJ trej...@gmail.com wrote: Many would argue that the version of IP is irrelevant, if you are permitting external hosts the ability to scan your internal network in an unrestricted fashion (no stateful filtering or rate limiting) you have already lost, you How do you propose to rate-limit this scanning traffic? More router knobs are needed. This also does not solve problems with malicious hosts on the LAN. A stateful firewall on every router interface has been suggested already on this thread. It is unrealistic. Even granting that, for the sake of argument - it seems like it would not be hard for $vendor to have some sort of emergency garbage collection routines within their NDP implementations ... ? How do you propose the router know what entries are garbage and which are needed? Eliminating active, good entries to allow for more churn would make the problem much worse, not better. -- Jeff S Wheeler j...@inconcepts.biz +1-212-981-0607 Sr Network Operator / Innovative Network Concepts
Re: NIST IPv6 document
On 1/5/2011 10:02, TJ wrote: Many would argue that the version of IP is irrelevant, if you are permitting external hosts the ability to scan your internal network in an unrestricted fashion (no stateful filtering or rate limiting) you have already lost, you just might not know it yet. Stateful filtering introduces its own set of scaling issues. ~Seth
Re: sudden low spam levels?
On Jan 3, 2011, at 1:04 55PM, Ken Chase wrote: I have two independent mailservers, and two other customers that run their own servers, all largely unrelated infrastructures and target domains, suddenly experiencing low levels of spam. Total emails/day dropping from some 175,000-250,000ish to 50-75,000ish (legit mail in the 2-5,000 per day, yes I have some high spam:legit customers...). 3 days in a row now at least, at quick glance. Did someone set up them the bomb? See http://krebsonsecurity.com/2011/01/taking-stock-of-rustock/ for a discussion of recent spam level trends. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: 2010 IPv4 (and IPv6) Address Use Report
On 4 Jan 2011, at 3:29, Iljitsch van Beijnum wrote: [...] Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. This changed yesterday. ARIN is now listed as the administrator for 45/8. Regards, Leo
Clearwire/Clear for branch office connectivity?
Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. We're looking at it for industrial telemetry, and have spoken to people using ATT and VZW who are doing the same, but we wanted to look at Clear as well. Curious as to reliability, link performance, and support quality. Thanks! Brandon -- Brandon Galbraith US Voice: 630.492.0464
Re: AltDB?
1) If ARIN doesn't provide the level of authentication you desire, as an ARIN member you should send a note to ppml each day until it's available this is not address policy. this is ops. surely one does not have to dirty one's self with the ppml list to get an ops fix done in arin. it is not address policy. i have a rumor that arin is delaying and possibly not doing rpki that seems to have been announced on the ppml list (to which i do not subscribe). as it has impact on routing, not address policy, across north america and, in fact the globe, one would think it would be announced and discussed a bit more openly and widely. randy
Re: NIST IPv6 document
On Jan 6, 2011, at 1:02 AM, TJ wrote: if you are permitting external hosts the ability to scan your internal network in an unrestricted fashion DCN aside, how precisely does one define 'internal network' in, say, the context of the production network of a broadband access SP, or hosting/colocation/VPS/IaaS SP? Surely you aren't advocating wedging stateful firewalls into broadband access networks or in front of servers, with all the DoS chokepoint breakage that implies? Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Jan 6, 2011, at 1:14 AM, Jeff Wheeler wrote: A stateful firewall on every router interface has been suggested already on this thread. It is unrealistic. It isn't just unrealistic, it's highly undesirable, since it represents an huge DoS state vector. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: Clearwire/Clear for branch office connectivity?
Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. Curious as to reliability, link performance, and support quality. Me too! I'd love to hear from anyone that's used it extensively. Thanks! Brandon -- Brandon Galbraith US Voice: 630.492.0464
Announcing the Community FlowSpec trial
Friends and colleagues, At NANOG 48 I talked about a community flow-spec service we were looking at trying to make work. This is the idea of using IETF RFC 5575 to pass around flow-based rules, in this case, primarily for dropping unwanted packets. This technology is not as widely deployed as traditional RTBH techniques for a number of reasons. However, we thought perhaps it was widely used enough, or could be, to justify what might be a helpful and free 3rd party feed of flow-spec routes to keep our networks a little bit cleaner. A trial of this feed based on the traditional bogon routes can be had by contacting me directly. We realize the traditional IPv4 reserved, special and unallocated IPv4 bogon address is dwindling. Maybe there is room for some other type of feed, but to justify that, we're looking to see if even enough people would set up this presumably simpler feed to help us and the community get some more experience with multi-hop flow-spec. Details in getting it up and running in your own test networks are here: http://www.cymru.com/jtk/misc/community-fs.html John
Re: Clearwire/Clear for branch office connectivity?
On Wed, 5 Jan 2011, tico wrote: Is anyone using Clearwire/Clear's wireless broadband offering for Me too! I'd love to hear from anyone that's used it extensively. I haven't in a few years (I worked for someone who thought of themselves as a clearwire competitor), but we replaced a bunch of them that customers had, we installed a few of them with our own stickers on them, and we always kept one in the truck for those times we couldn't hit our own networks but we could hit theirs... the gear was generally solid - as long as you could get a good signal. inside datacenters, basements, and telco huts, though, were not places that good signal was often available -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
RE: Clearwire/Clear for branch office connectivity?
My coworker has a total of 6 hours into calling each and every Clear number that is publically facing and has yet to reach a person that even understands the question. We have boiled it down to the Clear business model is designed merely to sell you the generic modem and have a nice day. There appears to be zero interest in their business model to accommodate the enterprise. I really hope I am wrong, and if someone has a number of someone willing to deal with the enterprise customer base PLEASE forward it on. Mike
RE: Clearwire/Clear for branch office connectivity?
There appears to be zero interest in their business model to accommodate the enterprise. In my own personal experience, there appears to be zero interest in their business model to accommodate the CUSTOMER. They go on and on about how their frequency-space gives them a competitive advantage, but their network is unreliable and extremely traffic policed (try downloading something. You MIGHT get close to the advertised speed for a few seconds, but you'll spend the next 2 hours browsing at the speed of mud when the traffic policer kicks in. Do it too often, and it seems to stop de-limiting you altogether). As far as I can tell, the issue isn't on the customer-leg, it's on their backhauls and core network. Worse, their customer service is nonexistent, and their cancellation policy is a nightmare (so bad that there's a class action against them - not sure where it's at, haven't checked in a while). I have heard horror stories from their employees, their resellers, and fellow former customers. They're filing/have filed for bankruptcy. How many letters does it take to spell 'broken'? If you have a POTS line at locations where you need a connection, find someone who will sell you dialup, or get 3G service from a cell carrier (careful - 4G Sprint service is provided by Clearwire). You will, sadly, be happier. Nathan (This is my own personal opinion based on my experiences and the experiences directly related to me by others. It does not reflect solid fact or reality. My employer probably thinks my opinion is false - and it may well be.)
Re: Clearwire/Clear for branch office connectivity?
On Wed, Jan 05, 2011 at 04:15:43PM -0600, Brandon Galbraith wrote: Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. We're looking at it for industrial telemetry, and have spoken to people using ATT and VZW who are doing the same, but we wanted to look at Clear as well. Curious as to reliability, link performance, and support quality. I replaced a 3mbps/768kbps ADSL provisioned through Qwest with Clearwire's home offering. I've been mostly satisfied from a cost/performance standpoint - for $55/mo I get a mostly equal replacement for the DSL as well as service for a second usb dongle for my laptop.I've had to go through an uncomfortable process with their support people on two occasions when their service was booting me off every 3-10 mins. Turns out somehow my home address changed in their system and they decided to treat my home modem as a traveling modem. As others have stated they seemed aloof and lacked access to more than a script and basic tools for troubleshooting. Service has been mostly reliable for me in the Seattle area. Transfer rates are sufficient. -m
Re: Announcing the Community FlowSpec trial
On Wed, Jan 05, 2011 at 05:46:36PM -0600, John Kristoff wrote: Friends and colleagues, At NANOG 48 I talked about a community flow-spec service we were looking at trying to make work. This is the idea of using IETF RFC 5575 to pass around flow-based rules, in this case, primarily for dropping unwanted packets. This technology is not as widely deployed as traditional RTBH techniques for a number of reasons. However, we thought perhaps it was widely used enough, or could be, to justify what might be a helpful and free 3rd party feed of flow-spec routes to keep our networks a little bit cleaner. A trial of this feed based on the traditional bogon routes can be had by contacting me directly. We realize the traditional IPv4 reserved, special and unallocated IPv4 bogon address is dwindling. Maybe there is room for some other type of feed, but to justify that, we're looking to see if even enough people would set up this presumably simpler feed to help us and the community get some more experience with multi-hop flow-spec. As a word of warning to anyone who wants to deploy this on their Juniper routers (what other router vendors support it? :P), there are some pretty serious performance considerations of which you should be aware. For example, we discovered that on MX routers (with classic I-chip DPCs, the performance should be somewhat better for Trio cards but we haven't fully tested the exact numbers yet), installing as few as a dozen flowspec routes can create firewall filters that use enough SRAM accesses that you will no longer be able to achieve line rate packets/sec. With a few more rules, you may find that your 10GE's will only be able to handle 3-5Mpps instead of the normal 14.8Mpps. When this happens, excess traffic above what the firewall filters can handle will be silently discarded, with no indicaton in SNMP or show interface that you're dropping packets (though you may be able to see it in show pfe statistics traffic as Info cell drops). I can't tell you what the performance numbers are for other platforms, but anyone thinking about turning on flowspec from a third party source (especially one who may be sending them a large number of rules) should give serious consideration to the potential impact on their network first. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: NIST IPv6 document
This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet. no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet. It may also be worth noting that typical size of an IPv4 subnet is a bit of a red herring; a v4 router that's responsible for /16 of directly attached /24's is still able to run into some serious issues. What's more important is the rate at which scanning can occur, which is largely a function of (for a remote attacker) speed of connection to an upstream; this problem is getting worse. A practical lesson is the so-called Kaminsky DNS vulnerability (which Kaminsky didn't actually discover - This issue was known back around 2000, at least, but at the time was deemed impractical to exploit due to bandwidth and processing limitations). We do need to be aware that continued increases in the available resources will change the viability of attacks in the future. The switch from IPv4 to IPv6 itself is such a change; it renders random trolling through IP space much less productive. We should not lose sight of the fact that this is generally a very positive feature; calls for packing IPv6 space more tightly serve merely to marginalize that win. We should be figuring out ways to make /64's work optimally, because in ten years everyone's going to have gigabit Internet links and we're going to need all the tricks we can muster to make an attacker's job harder. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: NIST IPv6 document
On Jan 6, 2011, at 8:57 AM, Joe Greco wrote: The switch from IPv4 to IPv6 itself is such a change; it renders random trolling through IP space much less productive. And renders hinted trolling far more productive/necessary, invariably leading to increased strain on already-brittle/-overloaded DNS, whois, route servers, et. al., not to mention ND/multicast abuse. We should not lose sight of the fact that this is generally a very positive feature; calls for packing IPv6 space more tightly serve merely to marginalize that win. Far from being a 'win', I believe it's either neutral or a net negative, due to the above implications. If we're looking at a near-future world filled with spimes, where every molecule in every nanomanufactured soda can has its own IPv6 address it uses to communicate via NFC or ZigBee or whatever during the assembly/recycling process, unnecessarily wasting IPv6 space isn't an optimal strategy. The alleged security benefits of sparse IPv6 addressing plans are a canard, IMHO. We should be figuring out ways to make /64's work optimally, because in ten years everyone's going to have gigabit Internet links and we're going to need all the tricks we can muster to make an attacker's job harder. These are diametrically-opposed, mutually-exclusive goals, IMHO. All in all, IPv6 is a net security negative. It has all the same problems of IPv4, plus new, IPv6-specific problems - *in hex*. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Problems with removing NAT from a network
I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim cannot be changed. At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed?
Re: Problems with removing NAT from a network
On Jan 6, 2011, at 9:38 AM, ML wrote: At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. They shouldn't be using IP addresses in configs, they should be using DNS names. Time to bite the bullet and get this fixed prior to their eventual forced migration to IPv6. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco jgr...@ns.sol.net wrote: This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet. no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet. It may also be worth noting that typical size of an IPv4 subnet is a bit of a red herring; a v4 router that's responsible for /16 of directly attached /24's is still able to run into some serious issues. It is uncommon for publicly-addressed LANs to be this large. The reason is simple: relatively few sites still have such an excess of IPv4 addresses that they can use them in such a sparsely-populated manner. Those that do have had twenty years of operational experience with generation after generation of hardware and software, and they have had every opportunity to fully understand the problem (or redesign the relevant portion of their network.) In addition, there is not (any longer) a standard, and a group of mindless zealots, telling the world that at /16 on your LAN is the only right way to do it. This is, in fact, the case with IPv6 deployments, and will drive what customers demand. To understand the problem, you must first realize that myopic standards-bodies have created it, and either the standards must change, operators must explain to their customers why they are not following the standards, or equipment vendors must provide additional knobs to provide a mitigation mechanism that is an acceptable compromise. Do the advantages of sparse subnets out-weigh the known security detriments, even if good compromise-mechanisms are provided by equipment vendors? Security by obscurity is an oft-touted advantage of IPv6 sparse subnets. We all know that anyone with a paypal account can buy a list of a few hundred million email addresses for next to nothing. How long until that is the case with lists of recently-active IPv6 hosts? What portion of attack vectors really depend on scanning hosts that aren't easily found in the DNS, as opposed to vectors depending on a browser click, email attachment, or by simply hammering away at www.*.com with common PHP script vulnerabilities? How many people think that massively-sparse-subnets are going to save them money? Where will these cost-efficiencies come from? Why can't you gain that advantage by provisioning, say, 10 times as large a subnet as you think you need, instead of seventy-quadrillion times as large? Is anyone really going to put their Windows Updates off and save money because they are comfortable that their hosts can't be found by random scanning? Is stateless auto-configuration that big a win vs DHCP? Yes, I should have participated in the process in the 1990s. However, just because the bed is already made doesn't mean I am willing to lay my customers in it. These problems can still be fixed before IPv6 is ubiquitous and mission-critical. The easiest fix is to reset the /64 mentality which standards-zealots are clinging to. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Problems with removing NAT from a network
The devil's in the details (obviously), and someone that reads into the scenario better than me might have a more direct suggestion, but... I'd start by moving the NAT at least one hop into the AS so that routing symmetry can be enforced there. This allows for multi-homing (asymmetric routing at the edge) without (before) dealing with the NAT issue (if there is one at that point). On Jan 5, 2011 9:39 PM, ML m...@kenweb.org wrote: I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim cannot be changed. At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed?
Re: Problems with removing NAT from a network
You didn't mention, but are you introducing a second border router? Is the new upstream circuit from a new provider, or is it a second, redundant circuit to the same provider in a different POP? Does your customer have their own portable address space, or are they using provider address space? I'll make some presumptions: yes, it is a different provider, and no, they don't have their own address space. Based on those guesses/presumptions, I'd push to acquire portable address space. Advertise it to both providers, carve a chunk of that address space off and route it to a firewall(s) to perform border NAT. Migrate old, provider dependent external NAT space to new, portable address space. -M On Wed, Jan 5, 2011 at 6:38 PM, ML m...@kenweb.org wrote: I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim cannot be changed. At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed?
Re: NIST IPv6 document
The switch from IPv4 to IPv6 itself is such a change; it renders random t= rolling through IP space much less productive. And renders hinted trolling far more productive/necessary, invariably leadi= ng to increased strain on already-brittle/-overloaded DNS, whois, route ser= vers, et. al., not to mention ND/multicast abuse. Of course, you *want* them attacking the lower layers, you don't want them attacking the more easily defended higher layers... got an investment in Cisco stock there? :-) But seriously, if your solution is to eliminate sparseness, then you've also just make attacking networks a whole lot easier. We should not lose sight of the fact that this is generally a very positi= ve feature; calls for packing IPv6 space more tightly serve merely to margi= nalize that win. Far from being a 'win', I believe it's either neutral or a net negative, du= e to the above implications. Then you need to re-evaluate; I'd much prefer having to protect resources like DNS servers. With a DNS server, I can monitor access trends, or set off excessive query alarms, and I can even write the code to do all that without having to create custom silicon to implement it. One can only imagine how frustrating a $GENERATE must be to a PTR-scanner. Why do we have to repeat all the mistakes of IPv4 in v6? Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made port-scanning easy, attractive, productive, and commonplace. If there are operational problems with IPv6, now's a great time to figure them out and figure out how to make it work well. Re-engineering the protocol at this late hour is unlikely to be productive; it took many years to get IPv6 into the state it is, and if we are going to go and change it all because you don't like sparseness, will it be ready to deploy before 2020? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: NIST IPv6 document
On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made port-scanning easy, attractive, productive, and commonplace. I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. If I've done what's necessary to secure my hosts/applications, host-/port-scanning isn't going to find anything to exploit (overly-aggressive scanning can be a DoS vector, but there are ways to ameliorate that, too). If I haven't done what's necessary to secure my hosts/applications, one way or another, they *will* end up being exploited - and the faux security-by-obscurity offered by sparse addressing won't matter a bit. This whole focus on sparse addressing is just another way to tout security-by-obscurity. We already know that security-by-obscurity is a fundamentally-flawed concept, so it doesn't make sense to try and keep rationalizing it in various domain-specific instantiations. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco jgr...@ns.sol.net wrote: This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet. no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet. It may also be worth noting that typical size of an IPv4 subnet is a bit of a red herring; a v4 router that's responsible for /16 of directly attached /24's is still able to run into some serious issues. It is uncommon for publicly-addressed LANs to be this large. The reason is simple: relatively few sites still have such an excess of IPv4 addresses that they can use them in such a sparsely-populated manner. Who said anything about sparsely populated? A typical hosting provider might well fit such a general picture. Those that do have had twenty years of operational experience with generation after generation of hardware and software, and they have had every opportunity to fully understand the problem (or redesign the relevant portion of their network.) No they haven't. I can think of relatively few networks that have survived twenty years, and the ones that I can think of are mostly .edu. Those of us who have been operating IP networks for that length of time probably see both the flaws in IPv4 and IPv6. In addition, there is not (any longer) a standard, and a group of mindless zealots, telling the world that at /16 on your LAN is the only right way to do it. This is, in fact, the case with IPv6 deployments, and will drive what customers demand. The concepts behind IPv4 classful addressing were flawed, but not unrealistic given the history. Various pressures existed to force the development of CIDR. It's not clear that those same pressures will force IPv6 to develop smaller networks - but other pressures *might*. I've yet to hear convincing reasons as to why they *should*. To understand the problem, you must first realize that myopic standards-bodies have created it, and either the standards must change, operators must explain to their customers why they are not following the standards, or equipment vendors must provide additional knobs to provide a mitigation mechanism that is an acceptable compromise. Do the advantages of sparse subnets out-weigh the known security detriments, even if good compromise-mechanisms are provided by equipment vendors? Quite frankly, as an interested party, I've been following all this for many years, and I am having a little trouble figuring out what you mean by the known security detriments in this context. Security by obscurity is an oft-touted advantage of IPv6 sparse subnets. We all know that anyone with a paypal account can buy a list of a few hundred million email addresses for next to nothing. How long until that is the case with lists of recently-active IPv6 hosts? Personally, I expect to see IPv6 privacy extensions become commonly used; it's a fairly comprehensive answer to that issue. What portion of attack vectors really depend on scanning hosts that aren't easily found in the DNS, as opposed to vectors depending on a browser click, email attachment, or by simply hammering away at www.*.com with common PHP script vulnerabilities? I see people scanning our IP space *all* *the* *time*. How many people think that massively-sparse-subnets are going to save them money? If it saves me from creeps trawling through our IP space, that's a savings. Where will these cost-efficiencies come from? Why can't you gain that advantage by provisioning, say, 10 times as large a subnet as you think you need, instead of seventy-quadrillion times as large? Because at ten times as large, they can still trawl. Is anyone really going to put their Windows Updates off and save money because they are comfortable that their hosts can't be found by random scanning? Is stateless auto-configuration that big a win vs DHCP? Yes, I should have participated in the process in the 1990s. However, just because the bed is already made doesn't mean I am willing to lay my customers in it. These problems can still be fixed before IPv6 is ubiquitous and mission-critical. The easiest fix is to reset the /64 mentality which standards-zealots are clinging to. Think you missed that particular boat a long time ago. The next ship will be departing in a hundred years or so, advance registration for the IPv7 design committee are available over there. ... 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,
RE: NIST IPv6 document
From: Dobbins, Roland Sent: Wednesday, January 05, 2011 7:19 PM To: Nanog Operators' Group Subject: Re: NIST IPv6 document On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. It will be a problem if people learn they can DoS routers by doing it by maxing out the neighbor table. If I've done what's necessary to secure my hosts/applications, host- /port-scanning isn't going to find anything to exploit (overly- aggressive scanning can be a DoS vector, but there are ways to ameliorate that, too). I don't think you are understanding the problem. The problem comes from addressing hosts that don't even exist. This causes the router to attempt to find that host. The v6 equivalent of ARP. At some point that table becomes full of entries for hosts that don't exist so there isn't room for hosts that do exist. This whole focus on sparse addressing is just another way to tout security-by-obscurity. We already know that security-by-obscurity is a fundamentally-flawed concept, so it doesn't make sense to try and keep rationalizing it in various domain-specific instantiations. No, it was designed to accommodate EUI-64 addresses which are to replace MAC-48 addresses at layer2. We currently create an EUI-64 address out of a MAC-48 in many cases during SLAAC but at some point the interfaces will be shipping with EUI-64 addresses. The world is running out of MAC-48 addresses. So at some point the MAC address will be the host address and it will be 64-bits long. It has nothing to do with security by obscurity.
Re: NIST IPv6 document
On Jan 6, 2011, at 10:42 AM, George Bonser wrote: It will be a problem if people learn they can DoS routers by doing it by maxing out the neighbor table. I understand this - that's a completely separate issue from the supposed benefits of sparse addressing for endpoint host security. I don't think you are understanding the problem. I've understood the problem for years, thanks, and have commented on it in other portions of this thread, as well as in may earlier threads around this general set of issues - and it's completely orthogonal to this particular discussion. Or are you saying that you think that the miscreants will simply and contritely abandon host-/port-scanning as a) a host-discovery mechanism and b) as a DoS mechanism if everyone magically adopts sparse addressing? Somehow, I don't think that's very likely. ; Also, see my previous comments in re the negative implications of hinted scanning. It has nothing to do with security by obscurity. You may wish to re-read what Joe was saying - he was positing sparse addressing as a positive good because it will supposedly make it more difficult for attackers to locate endpoints in the first place, i.e., security through obscurity. I think that's an invalid argument. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: reporting physical plant damage to ATT?
- Original Message - From: Jo Rhett jrh...@netconsonance.com On Nov 25, 2010, at 2:11 PM, Kevin Oberman wrote: Have you tried 611 (from an ATT land-line phone)? Many people don't have one. I haven't had one for over 12 years now, nor have any of my employers for the last 8 years. For what its worth, I *have* tried reporting outside plant damage in GTE FL to Verizon; it's impossible to find anyone who has any clue WTF you're talking about. I call my ex-boss's son, who works there, and ask him to pass it along to his dispatcher as something *he's* seen. Cheers, -- jr 'I realize this doesn't scale' a
ARIN and the RPKI (was Re: AltDB?)
Sorry for the subject change, it seems now we're talking about something perhaps more relevant to me (security and routing stuff) On Wed, Jan 5, 2011 at 5:32 PM, Randy Bush ra...@psg.com wrote: i have a rumor that arin is delaying and possibly not doing rpki that seems to have been announced on the ppml list (to which i do not I have heard this as well ... the message in the archive is: (arin-announce actually, not ppml) http://lists.arin.net/pipermail/arin-announce/2010-December/001107.html Essentially the note says that Kosters crew are delaying until Q2-2011 the deployment of RPKI services (nebulous 'other features need to be implemented due to security concerns' is the stated reason) subscribe). as it has impact on routing, not address policy, across north america and, in fact the globe, one would think it would be announced and discussed a bit more openly and widely. I agree... so, what is the RPKI for and why should ops/security folks care? (and should we care enough to poke our local ARIN constabulary in the eye with a sharp stick?) I'm of the belief that if we (ops/security folks) feel the need to have a more secure routing infrastructure so we can hope to avoid incidents like: (quick examples, there are many others like these) o AS7007 full-table re-announce + re-originate o ConEdison hijack + re-originate o Pakistan/YT hijack + re-originate o Pilosov/Kapela hijacks/manipulations o Christmas TurkTelecom leak/hijack o PRC network leakages/hijacks/etc of April 2010 (Note: let's not debate if the above incidents are one/the-other hijack/mistake/etc, the simple fact is traffic was diverted and some better filtering/control would have avoided these failures in our system) We need at least these things to exist: o an accurate mapping of resource (netblock/asn) to authorized-entity (RIR/NIR/LIR/Customer/...) o a system to manage this data for our routing equipment o protocol enhancements that can be used to help propagate the mapping information or at the least help a router programmaticly understand if a resource is being used by the authorized entity o routing software that can digest the enhanced data o routing hardware that won't crumple under the weight of (what seems like) heavier weight routing protocol requirements I believe the lynch-pin in this is the accurate mapping of resources to authorized users, I believe that is supposed to be the RPKI system. I believe that the RPKI will tell me, an end-operator, that 63.0.0.0/9 was handed from IANA to ARIN to UUNET/VerizonBusiness and that this is being properly announced with an Origin-AS of 701. Having the service run by these organizations seems reasonable to me... IANA signs down to the RIR (ARIN in my example) and ARIN signs to VZB who can choose to sign down to their customers if necessary. Today there is a very loose, in all regions not just ARIN's, association with lots of cruft and inaccuracies. The RPKI, operated by RIR's, would provide some solid linkage and authority between resources and owners, it should help to enforce cruft management as well as provide mechanical (and relatively simple) management of the data and associated filtering/etc on devices. There is, of course, some risk with this model and we should take the time to accept/discuss that as well. Danny has had lots of good input on this topic, I'd hope that other folks who've been through longer term ops battles with filtering (jared, shane, charles gucker, rs, ras, ...) and the like can take some time to think about this problem. I'd love it if we could have some reasoned discussion here as well. Finally, everyone should go poke their ARIN corporate representative(s) (or email the BoT or AC folks directly even?) with their thoughts on whether or not the RPKI system and Routing Security are important items for ARIN (as one RIR) to pursue for the health of the Internet and Ops Sanity. The BoT folks are listed at: https://www.arin.net/about_us/bot.html (with email addresses even!) The AC folks are listed at: https://www.arin.net/about_us/ac.html -Chris
Re: Problems with removing NAT from a network
On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 6, 2011, at 9:38 AM, ML wrote: At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. They shouldn't be using IP addresses in configs, they should be using DNS names. Time to bite the bullet and get this fixed prior to their eventual forced migration to IPv6. Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks. Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals Cameron = http://groups.google.com/group/tmoipv6beta = Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: ARIN and the RPKI (was Re: AltDB?)
We need at least these things to exist: o an accurate mapping of resource (netblock/asn) to authorized-entity (RIR/NIR/LIR/Customer/...) o a system to manage this data for our routing equipment see all the sidr documents in last call to go from i-ds to rfcs. oh, you co-chair sidr :) o protocol enhancements that can be used to help propagate the mapping information or at the least help a router programmaticly understand if a resource is being used by the authorized entity see draft-ietf-sidr-rpki-rtr-07 o routing software that can digest the enhanced data in test. rumors of going normal release from at least one vendor in q2 o routing hardware that won't crumple under the weight of (what seems like) heavier weight routing protocol requirements actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs There is, of course, some risk with this model and we should take the time to accept/discuss that as well. some guidance toward ameliorating the risks are in draft-ietf-sidr-rpki-origin-ops-00.txt. input from ops into all this stuff would be most welcome. randy
RE: NIST IPv6 document
I've understood the problem for years, thanks, and have commented on it in other portions of this thread, as well as in may earlier threads around this general set of issues - and it's completely orthogonal to this particular discussion. I suppose what confused me was this: I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. If I've done what's necessary to secure my hosts/applications, host-/port-scanning isn't going to find anything to exploit (overly-aggressive scanning can be a DoS vector, but there are ways to ameliorate that, too). I thought the entire notion of actually getting to a host was orthogonal to the discussion as that wasn't the point. It wasn't about exploitation of anything on the host, the discussion was about the act of scanning a network itself being the problem. If network devices can be degraded simply by scanning the network, it is going to become *very* commonplace. But the sets of problems are different for an end user network vs. a service provider network. For a transit link you might disable ND and configure static neighbors which would inoculate that link from such a neighbor table exhaustion attack. For an end network, the problems are different.
Re: NIST IPv6 document
On 1/5/2011 10:18 PM, Dobbins, Roland wrote: This whole focus on sparse addressing is just another way to tout security-by-obscurity. We already know that security-by-obscurity is a fundamentally-flawed concept, so it doesn't make sense to try and keep rationalizing it in various domain-specific instantiations. I agree. It's not the hosts I'm worried about protecting, it's the potential noise directed at the IPv6 space, intentional/irrational scan or otherwise generated traffic. Still, the idea that nobody will scan a /64 reminds me of the days when 640K ought to be enough for anybody, 56-bit DES ought to be good enough to never be cracked, 10 megabits was astoundingly fast, a T1 was more than enough commodity, and a 300-baud acoustic coupler was a modern marvel. I hesitate to write anything off to impossibility, having witnessed the 8 to 16 to 32 to 64-bit processor progression :) But perhaps it's time for Moore to rest and we can make assumptions about that impossibility. Scanned or not, IPv6 still presents a very large route target. Given the transient / spoofed / backscatter / garbage / scan / script kiddie noise that accidentally lands in my IPv4 space, I shudder to think of the noise level of the many-orders-of-magnitude-greater IPv6 space. And the depth of infrastructure at which you can decide the traffic is bogus is much greater with IPv6. Most will end up on the target network anyway, no? Jeff
Re: ARIN and the RPKI (was Re: AltDB?)
On Wed, Jan 5, 2011 at 11:16 PM, Randy Bush ra...@psg.com wrote: We need at least these things to exist: o an accurate mapping of resource (netblock/asn) to authorized-entity (RIR/NIR/LIR/Customer/...) o a system to manage this data for our routing equipment see all the sidr documents in last call to go from i-ds to rfcs. oh, you co-chair sidr :) yes, sorry I should have been more open ... i do co-chair (with sandy murphy) the sidr-wg at the IETF. o protocol enhancements that can be used to help propagate the mapping information or at the least help a router programmaticly understand if a resource is being used by the authorized entity see draft-ietf-sidr-rpki-rtr-07 o routing software that can digest the enhanced data in test. rumors of going normal release from at least one vendor in q2 o routing hardware that won't crumple under the weight of (what seems like) heavier weight routing protocol requirements actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs CPU + RAM both parts of the vector matter. (but you knew this) Some of the interesting data would, I think, be good for ops folks to see more openly, things that may actually affect their purchasing and design decisions even! Danny's had some good presentation material about changes in spec/implementations that have altered drastically the update load on devices in actual networks. There is, of course, some risk with this model and we should take the time to accept/discuss that as well. some guidance toward ameliorating the risks are in draft-ietf-sidr-rpki-origin-ops-00.txt. input from ops into all this stuff would be most welcome. yes (as the co-chair) yes (as the OP... more input/thought/discussion) and looking at the: https://www.arin.net/about_us/bot/index.html it looks like the BoT is due to have a meeting either this week or next? (they seem to always have one in the first week or two of the year?) so again speak up here AND perhaps send a note the BoT or your ARIN Rep's way now. -Chris
Re: Announcing the Community FlowSpec trial
On Wed, Jan 5, 2011 at 7:51 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Wed, Jan 05, 2011 at 05:46:36PM -0600, John Kristoff wrote: Friends and colleagues, At NANOG 48 I talked about a community flow-spec service we were looking at trying to make work. This is the idea of using IETF RFC 5575 to pass around flow-based rules, in this case, primarily for dropping unwanted packets. snip As a word of warning to anyone who wants to deploy this on their Juniper routers (what other router vendors support it? :P), there are some pretty serious performance considerations of which you should be aware. For example, we discovered that on MX routers (with classic I-chip DPCs, the performance should be somewhat better for Trio cards but we haven't fully tested the exact numbers yet), installing as few as a dozen flowspec routes can create firewall filters that use enough SRAM 'as few as a dozen' - of things like: (forgive the hackery into cisco-ese) deny ip 127.0.0.0 0.255.255.255 any permit ip any any or with port/protocol/flags/sizes/etc ? (can you provide some examples of your dozen-or-so - give folk a starting point in their testing) -chris
Re: NIST IPv6 document
On Jan 6, 2011, at 11:16 AM, George Bonser wrote: I thought the entire notion of actually getting to a host was orthogonal to the discussion as that wasn't the point. It wasn't about exploitation of anything on the host, the discussion was about the act of scanning a network itself being the problem. That's a separate sub-thread. Joe was specifically talking about sparse addressing as a way to keep the attackers from finding end-hosts. My view is that a) nothing will keep the attackers from finding the end-hosts, b) they'll scan, anyways, c) they'd do hinted scanning (DNS/whois/routing tables) which will have its own negative second-order effects, and therefore c) the scanning issue in terms of endpoint security is a red herring. If network devices can be degraded simply by scanning the network, it is going to become *very* commonplace. They already can be, and it's going to become more commonplace as a DoS attack vector, concur w/you 100%. But the sets of problems are different for an end user network vs. a service provider network. For a transit link you might disable ND and configure static neighbors which would inoculate that link from such a neighbor table exhaustion attack. If you're using /64s for your p2p links, the router's still been turned into a sinkhole, though. For an end network, the problems are different. Concur again. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: ARIN and the RPKI (was Re: AltDB?)
On Jan 6, 2011, at 11:16 AM, Randy Bush wrote: actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash. Concur on all the other points, however. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: Problems with removing NAT from a network
In message aanlktimkgpyky_aka5px4-ca-3=oufhgbnenrkpmp...@mail.gmail.com, Came ron Byrne writes: On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 6, 2011, at 9:38 AM, ML wrote: At least not without some painful rebuilds of criticals systems which ha= ve these IPs deeply embedded in their configs. They shouldn't be using IP addresses in configs, they should be using DNS= names. =A0Time to bite the bullet and get this fixed prior to their eventu= al forced migration to IPv6. Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks. Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things. Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals Cameron =3D=3D=3D=3D=3D=3D=3D=3D=3D http://groups.google.com/group/tmoipv6beta =3D=3D=3D=3D=3D=3D=3D=3D=3D Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ARIN and the RPKI (was Re: AltDB?)
On Wed, Jan 5, 2011 at 11:30 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 6, 2011, at 11:16 AM, Randy Bush wrote: actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash. I think ACLs here means prefix-lists ... or I hope that's what Randy meant? (prefix-lists are still, I believe, handled in the router CPU, and the normal router OS not in hardware) Concur on all the other points, however. cool, thanks! -chris Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Next generation TV over the Internet: This revolution will be televised
Lenny Giuliano of Juniper (IETF MBONED co-chair) has written an article in Network World that I thought NANOGers might be interested in : http://www.networkworld.com/news/tech/2011/010511-tech-update-next-gen-tv.html He clearly describes the need for multicast in the upcoming video-centric Internet and how the AMT protocol can help by providing automatic tunnels between unicast-only users and multicast-enabled content, and provides a vision for a Internet NextGenTV. Regards Marshall
Re: Problems with removing NAT from a network
On Wed, Jan 5, 2011 at 8:31 PM, Mark Andrews ma...@isc.org wrote: In message aanlktimkgpyky_aka5px4-ca-3=oufhgbnenrkpmp...@mail.gmail.com, Came ron Byrne writes: On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 6, 2011, at 9:38 AM, ML wrote: At least not without some painful rebuilds of criticals systems which ha= ve these IPs deeply embedded in their configs. They shouldn't be using IP addresses in configs, they should be using DNS= names. =A0Time to bite the bullet and get this fixed prior to their eventu= al forced migration to IPv6. Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks. Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things. Thanks for the tip. But, there are legitimate business reason in various different types of networks for various strategies, thanks for plugging the one your organization makes. I am tired of the IPv6 transition flavor of the day war. The reality for content folks is that there will be IPv4 host, IPv6 hosts, and dual stack hosts. Content needs to be dual-stack to reach everyone the best way (native), but if they lack dual-stack and they use IPv4 literals, they are going to lose eyeballs. End of story. Content folks-- do yourself a favor and follow Roland's advice (also in RFC 1958) and don't use address literals, use names. And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws. If you know others, strengthen your case and add them to the list so that all parties can benefit. Otherwise, it is just a few poorly designed internet services that will be in a rush to fix services when users complain or there web pages hits start trending down while their competitors trend up. Cameron Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals Cameron =3D=3D=3D=3D=3D=3D=3D=3D=3D http://groups.google.com/group/tmoipv6beta =3D=3D=3D=3D=3D=3D=3D=3D=3D Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: NIST IPv6 document
Still, the idea that nobody will scan a /64 reminds me of the days when 640K ought to be enough for anybody, ... We really need to wrap our heads around the orders of magnitude involved here. If you could scan an address every nanosecond, which I think is a reasonable upper bound what with the speed of light and all, it would still take 500 years to scan a /64. Enumerating all the addresses will never be practical. But there's plenty of damage one can do with a much less than thorough enumeration. And the depth of infrastructure at which you can decide the traffic is bogus is much greater with IPv6. Most will end up on the target network anyway, no? I get the impression that we're just beginning to figure out all the ways that bad things can happen when friends or foes start using all those addresses. For example, over in the IRTF ASRG list we're arguing about what to do with IP based blacklists and whitelists, since spammers could easily use a unique IP address for every message they ever send. (Please don't argue about that particular issue here, but feel free to do so in the ASRG.) Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Problems with removing NAT from a network
On 1/5/2011 8:47 PM, Cameron Byrne wrote: And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws. And the list looks like it does because the list only shows a *few* web sites. Other surveys have shown significantly more cases. ( http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02#appendix-B An examination of Alexa's top 1 million domains [Alexa] at the end of August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 address literals. And the list looks like is does because the list only shows a few *web sites*. Quite a few network protocols, particularly peer-to-peer protocols, rely on moving around the IP address literals of peers via mechanisms other than DNS. This includes BitTorrent, Adobe's RTMFP, and Skype's proprietary protocol, and every VoIP system using STUN and/or ICE, to name just a few. Once users figure out that none of those will work when they use you as an ISP, they'll find one that's chosen a better transition technology. Also note that DNSSEC end-to-end and DNS64/NAT64 are mutually exclusive. Now that DNSSEC is actually getting some traction, that's just one more reason to chose a different way to transition. Matthew Kaufman
Re: ARIN and the RPKI (was Re: AltDB?)
actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash. really? it was measured on a GSR. full check on a prefix, 10usec. that's microseconds. as chris pointed out, though, one pays for having the data in the trie, i.e. in ram. but not a lot. randy
Re: NIST IPv6 document
It has nothing to do with security by obscurity. You may wish to re-read what Joe was saying - he was positing sparse addres= sing as a positive good because it will supposedly make it more difficult f= or attackers to locate endpoints in the first place, i.e., security through= obscurity. I think that's an invalid argument. That's not necessarily security through obscurity. A client that just picks a random(*) address in the /64 and sits on it forever could be reasonably argued to be doing a form of security through obscurity. However, that's not the only potential use! A client that initiates each new outbound connection from a different IP address is doing something Really Good. It may help to think of your Internet address plus port number as being just a single quantity in some senses. As it stands with IPv4, when you see packets from 12.34.56.78, you pretty much know there's a host or something interesting probably living there. You can then try to probe one of ~64K ports, or better yet, all of them, and you have a good chance of finding something of interest. If you have potentially 80 bits of space to probe (16 bits of ports on each of 64 bits of address), you're making a hell of a jump. If you don't understand the value of such an increase in magnitude, I invite you to switch all your ssh keys to 56 bit. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: ARIN and the RPKI (was Re: AltDB?)
I think ACLs here means prefix-lists ... or I hope that's what Randy meant? sorry. yes, irr based prefix lists. and, sad to say, data which have sucked for 15+ years. i was the poster child for the irr, and it just never took off. [ irr data are pretty bad except for some islands where there is culture of maintining them. and, as it is a global internet, islands don't help much. europe and japan are two islands with better than the average irr data quality. and they have rpki rolling to varied degrees. ] randy
Re: Problems with removing NAT from a network
On Jan 5, 2011, at 10:31 PM, Mark Andrews wrote: Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things. Or just run a dual-stack network, with centralized NAT44, and avoid the headache of tunneling. If you're going to run two protocol families on the end host, and deal with the issues that causes, why require tunneling to make it work? Is it so hard to forward IPv4 packets natively? Cheers, -Benson
Re: NIST IPv6 document
Is there any reason we really need to care what size other people use for their Point to Point links? Personally, I think /64 works just fine. I won't criticize anyone for using it. It's what I choose to use. However, if someone else wants to keep track of /112s, /120s, /124s, /126s, or even /127s on their own network, so be it. The protocol allows for all of that. If vendors build stuff that depends on /64, that stuff is technically broken and it's between the network operator and the vendor to get it resolved. Owen On Jan 5, 2011, at 4:29 AM, Dobbins, Roland wrote: On Jan 5, 2011, at 7:21 PM, Jeff Wheeler wrote: please explain why this is in any way better than operating the same LAN with a subnet similar in size to its existing IPv4 subnets, e.g. a /120. Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space is, I know, and reject that argument out of hand) and b) it turns the routers/switches into sinkholes. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Jan 5, 2011, at 7:04 AM, Jack Bates wrote: On 1/5/2011 6:29 AM, Dobbins, Roland wrote: Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space is, I know, and reject that argument out of hand) and b) it turns the routers/switches into sinkholes. Except someone was kind enough to develop a protocol that requires /64 to work. So then there is the SLAAC question. When might it be used? With routers, I usually don't use SLAAC. The exception is end user networks, which makes using SLAAC + DHCPv6-PD extremely dangerous for my edge routers. DHCPv6 IA_TA + DHCPv6-PD would be more sane, predictable, and filterable (and support longer than /64) thought my current edge layout can't support this (darn legacy IOS). I would love a dynamic renumbering scheme for routers, but until all routing protocols (especially iBGP) support shifting from one prefix to the next without a problem, it's a lost cause and manual renumbering is still required. Things like abstracting the router id from the transport protocol would be nice. I could be wrong, but I think ISIS is about it for protocols that won't complain. All that said, routers should be /126 or similar for links, with special circumstances and layouts for customer edge. Why shouldn't I use /64 for links if I want to? I can see why you can say you want /126s, and that's fine, as long as you are willing to deal with the fall-out, your network, your problem, but, why tell me that my RFC-compliant network is somehow wrong? For server subnets, I actually prefer leaving it /64 and using SLAAC with token assignments. This is easily mitigated with ACLs to filter any packets that don't fall within the range I generally use for the tokens, with localized exceptions for non-token devices which haven't been fully initialized yet (ie, stay behind stateful firewall until I've changed my IP to prefix::0-2FF). I haven't tried it, but I highly suspect it would fail, but it would be nice to use SLAAC with longer than /64. SLAAC cannot function with longer than /64 because SLAAC depends on prefix + EUI-64 = address. Owen
