Re: HTTPS-everywhere vs. proxy caching
On Fri, May 3, 2013 at 3:33 PM, Wes Felter w...@felter.org wrote: On 5/3/13 2:06 PM, Jay Ashworth wrote: It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia. That traffic's not cacheable, is it? This has been discussed over the last year in the IETF HTTP WG in the context of SPDY and HTTP 2.0. Today this traffic is not cacheable. Some people are proposing to have a mode that is end-to-end secure and shows the lock icon in the browser and a different mode that uses SSL to the cache and SSL from the cache to the origin and doesn't show a lock. For networks that have traffic inspection requirements (e.g. education/enterprise) there has also been discussion about a signaling protocol for the network to indicate to browsers that all non-proxied traffic will be dropped. Transparent proxies are evil and one of the goals of HTTP 2.0 is to make proxies visible to the browser/user so they can choose whether to consent to having their traffic proxied. -- Wes Felter Thanks for the summary, Wes. If operators have thoughts on this issue, there is still discussion going on about HTTP/2.0. As Wes notes, HTTP/2.0 is going to have a strong emphasis on TLS, as with SPDY.Please send comments to the WG mailing list: http://tools.ietf.org/wg/httpbis http://lists.w3.org/Archives/Public/ietf-http-wg/ Cheers, --Richard
Re: Announcing a reserved ASN?
Some links: http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf https://tools.ietf.org/html/rfc6793 On Sun, Feb 3, 2013 at 11:15 AM, Brandon Ross br...@pobox.com wrote: I strongly recommend that you read about and fully understand how 4-byte ASNs work, and their use of AS23456 before you continue this thread. On Sun, 3 Feb 2013, Suresh Ramasubramanian wrote: I do believe, as has been pointed out to me elsewhere that this is what shows up when there's a 64 bit ASN and router software that doesn't grok 64 bit ASNs So, completely by chance that one such as belongs to what looks like a bulk mailer --srs (htc one x) On 03-Feb-2013 9:02 PM, Dave Pooser dave.na...@alfordmedia.com wrote: On 2/3/13 9:04 AM, Rich Kulawiec r...@gsp.org wrote: On Sun, Feb 03, 2013 at 06:12:32PM +0530, Suresh Ramasubramanian wrote: AS23456 is currently announcing a good few netblocks (which don't have a very good smtp reputation, by the way). To say the least. A quick rDNS scan reveals that those netblocks include: 8448 addresses 6932 return nxdomain 512 return servfail 1004 with rDNS entries Those 1004 hosts with rDNS account for 36 domains: snip long list of spammy domains Just as another data point, the domain names you listed hit on enough URL blacklists that Spamassassin quarantined the message for me (and would have rejected it during the SMTP transaction had the NANOG server not been listed on DNSWL-High). Spam hosts plus fake ASN = paging the Spamhaus DROP maintainers to the white courtesy phone -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross
Re: btw, the itu imploded
See also: http://www.ipv.sx/wcit/ On Fri, Dec 14, 2012 at 2:41 PM, Randy Bush ra...@psg.com wrote:
Re: Middle East MPLS
Where MENOG list == me...@menog.net http://www.menog.org/ On Wed, Nov 28, 2012 at 3:31 PM, Scott Weeks sur...@mauigateway.com wrote: --- 2asx1y...@sneakemail.com wrote: Anyone from Etisalat on list? I'm interested in some MPLS connectivity into Dubai. Try on the MENOG list. scott
Re: Big day for IPv6 - 1% native penetration
On Mon, Nov 26, 2012 at 12:15 PM, Cameron Byrne cb.li...@gmail.com wrote: On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: Ipv6 is not important for users, it is important for network operators who want to sustain their business. I agree with the first part; not sure I agree with the second part. Nope. Nobody will leave money on the table by alienating users. I think it may be possible to make money with compelling IPv6-only content/services/applications. I disagree, i simply see an additional fee for IPv4 coming about. +1 And that in itself seems like it would make IPv6-reachable things a lot more compelling.
Re: authority to route?
I think Heather was pointing out that this would be a good time to actually use it. On Fri, Nov 16, 2012 at 12:55 PM, valdis.kletni...@vt.edu wrote: On Thu, 15 Nov 2012 23:05:39 -0800, Kyle Creyts said: Jeez, isn't RPKI supposed to solve this problem? That would presume the existence of a deployed system that everybody actually used.
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
The folks that have done the most work in enabling IPv6-only end users seem to be CERNET2 in China. To let people get to v4, they're using what they call IVI (get it?), which is basically NAT64+DNS64. http://tools.ietf.org/html/rfc6219 http://en.wikipedia.org/wiki/NAT64 If you don't mind running IPv4 in a tunnel over that IPv6 network, you can do DSlite or 4rd http://tools.ietf.org/html/rfc6333 http://tools.ietf.org/html/draft-despres-intarea-4rd-01 http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28DS-Lite.29 On Friday, September 21, 2012, Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: CAIDA's AS-rank project
No IPv6? On Thu, Sep 6, 2012 at 6:46 PM, Matthew Luckie m...@caida.org wrote: Hello, We have been working on refreshing the data and algorithms behind CAIDA's as-rank project. We have published AS-relationships and AS-rankings computed for June 2012. We are currently seeking further validation of our rankings and relationship inferences. http://as-rank.caida.org/ The core of the algorithm is the inference of business relationships. Over the past two years we have received a significant amount of ground truth from operators through the corrections facility provided within AS-rank: in particular we obtained 1200 p2p relationships as a result of our previous algorithm that assigned many more customer/provider (c2p) relationships than ASes had in reality. Our intuition is that network owners are a lot more concerned when we infer a provider relationship that is actually a peer relationship, but are less motivated to validate other inferences. We have validated our algorithm against available ground truth and find our relationship inferences have a 99.1% positive predictive value (PPV) for c2p and 94.7% for p2p for the validation data we have available. Because customer cone computation depends on the accuracy of our c2p inferences, we are reasonably confident in our computed rankings. We are now soliciting further feedback in any shape and form offered. The as-rank website provides the ability for operators to submit corrections through the right-most corrections button on an individual ASes information page, and relationships ground-truth is solicited through that channel, if at all possible. Other feedback, on or off-list, would also be appreciated. If you are curious as to why a particular relationship was inferred, please get in contact with me. Some ASes have advised of a particular business relationship in the past, but when I drill down into the data it turns out they have a misconfiguration and are leaking routes to a peer. At a minimum, this might be a useful sanity check for some ASes who may be providing free transit without realising it. In the future, we plan to annotate each relationship with examples as to why it was inferred the way it was, but we have not yet got that far yet. Thanks, Matthew Luckie CAIDA
Re: RPKI Pilot Participant Notice
I think Randy meant to imply that requiring anyone that wants to actually use the RPKI to make a legal agreement with ARIN might not be the best way to encourage deployment. On Wed, Sep 5, 2012 at 2:56 PM, Mark Kosters ma...@arin.net wrote: On 9/5/12 3:26 AM, Randy Bush ra...@psg.com wrote: can you find the fatal flaw? [ hint: how does an isp in phnom penh validate my route? ] randy Hi Randy Your question is a bit cryptic. Could you be more specific about your concern? Thanks, Mark
Re: Regarding smaller prefix for hijack protection
This seems like an opportune time to remind people about RPKI-based origin validation as a hijack mitigation: http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08 http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/15-2s/irg-origin-as.pdf I haven't run the numbers, but it seems like doing RPKI-based origin validation is probably a lot cheaper than upgrading routers to store a fully deaggregated route table :) On Tue, Sep 4, 2012 at 12:29 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: The thing to acknowledge is that you've realized it otherwise if you follow the CIDR report than you will find bunch of arrogant folks/SPs not willing to understand the dilemma they are causing through de-aggregation. Regards, Aftab A. Siddiqui On Tue, Sep 4, 2012 at 10:19 AM, Anurag Bhatia m...@anuragbhatia.com wrote: I didn't realized the routing table size problem with /24's. Stupid me. Thanks everyone for updates. Appreciate good answers.
Re: Drupal-GEO maping
http://lmgtfy.com/?q=drupal+geo+ip http://lmgtfy.com/?q=joomla+geo+ip On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatia m...@anuragbhatia.com wrote: Hi James Nice question. I am interested if someone can suggest some similar extension or some code to integrate it within Joomla too. Thanks. On Wed, Jun 6, 2012 at 12:42 AM, James Smith ja...@smithwaysecurity.comwrote: Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854
Re: rpki vs. secure dns?
i can tell more than that. rover is a system that only works at all when everything everywhere is working well, and when changes always come in perfect time-order, Exactly like DNSSEC. no. dnssec for a response only needs that response's delegation and signing path to work, not everything everywhere. My impression was that ROVER does not need everything, everywhere to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong. RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'. So in RPKI, partial data – so you failed to fetch one of the ROAs in the set – can make something 'invalid' or 'unknown' that should actually be 'valid'. http://tools.ietf.org/html/rfc6483#page-3 I wouldn't read that as saying that the RPKI requires you to have full data in order to provide any benefit. Where sufficient certs and ROAs exist to validate an announcement, you can mark it valid/invalid -- just like ROVER, but with a harder failure case. As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.) Of course, there's a reason that an announcement that contradicts a ROA is marked as invalid [RFC6483]. Such announcements are hijacks, the attacks that the RPKI is designed to prevent. If ROVER doesn't provide a hard fail here, then it would seem to not be providing much security benefit. I agree with the person higher up the thread that ROVER seems like just another distribution mechanism for what is essentially RPKI data. --Richard
Re: rpki vs. secure dns?
So in RPKI, partial data – so you failed to fetch one of the ROAs in the set – can make something 'invalid' or 'unknown' that should actually be 'valid'. http://tools.ietf.org/html/rfc6483#page-3 I wouldn't read that as saying that the RPKI requires you to have full data in order to provide any benefit. Where sufficient certs and ROAs exist to validate an announcement, you can mark it valid/invalid -- just like ROVER, but with a harder failure case. I don't mean that you need ROAs describing every route announcement in existence for it to be useful. What I mean is for an operator to determine if a route announcement is RPKI valid, invalid or unknown, they will need *all* ROAs that *have been created*. If they miss a ROA in the data set during the fetching process, a route can end up with the incorrect validity state. See my example. Oh, ok sure. The validation outcomes with full data will be different than with partial data. But that's why the unknown state is there -- as there's more data, things move from unknown to valid/invalid. As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.) Of course, there's a reason that an announcement that contradicts a ROA is marked as invalid [RFC6483]. Such announcements are hijacks, the attacks that the RPKI is designed to prevent. If ROVER doesn't provide a hard fail here, then it would seem to not be providing much security benefit. That does seem the case. I don't think ROVER provides a hard fail. Can someone confirm? I agree with the person higher up the thread that ROVER seems like just another distribution mechanism for what is essentially RPKI data. But does that distribution method easily allow you to get the full set of available data? From what little I know, it seems to me that ROVER is optimized for point queries, rather than bulk data access. Which is the opposite of making it easy to get full data :) --Richard
Re: Operation Ghost Click
ISPs in the Netherlands have had a botnet treaty in effect since 2009, which calls for blocking, user notification, and inter-ISP information sharing. http://ripe59.ripe.net/presentations/huijbregts-botnet-convenant.pdf http://www.darkreading.com/blog/227700601/dutch-isps-sign-anti-botnet-treaty.html I don't have any data about how effective it's been, though. On Tue, May 1, 2012 at 8:26 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: On 4/26/12 10:03 PM, Jeff Kell jeff-k...@utc.edu wrote: And what about the millions of users unknowingly infected with something else ?? (We have enough trouble isolating/remediating issues among our relatively small user base, I'd hate to be facing a major ISP size support/remediation effort...) Does anyone have a plan? Well, there's the new botnet code of conduct think (Mike O'Reirdan can chime in with more info here). Plus ISPs like the one I work at (Comcast) have been doing bot notification and remediation for some time now. I know other ISPs have different approaches, and so different bot programs, but the majority of them are doing something (with a few exceptions). Jason
Re: Cool IPs: 1.234.35.245 brute force SSHing
While you're in Korea, you could talk to Samsung as well about 123.32.0.0/12 (including 123.45.67.89). Closer to home, you could also talk to ATT about 12.0.0.0/8 (12.34.56.78). --Richard On Sat, Feb 25, 2012 at 2:26 AM, Joel M Snyder joel.sny...@opus1.com wrote: Normally I wouldn't say anything to anyone about anything so mundane as brute-force SSH attacks, but this one caught my eye just because of the IP address: 1.234.35.245 I wanna get a connection in Korea so I can have 1.234.56.78. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.com http://www.opus1.com/jms
HP contact?
Anyone have a clueful contact at HP? One of their proprietary DHCP features is squatting on an IANA-registered code point. Thanks, --Richard
Re: do not filter your customers
I think if we asked telstra why they didn't filter their customer some answer like: 1) we did, we goofed, oops! 2) we don't it's too hard 3) filters? what? I suspect in the case of 1 it's a software problem that needs more belts/suspenders I suspect in the case of 2 it's a problem that could be shown to be simpler with some resource-certification in place I suspect 3 is not likely... (or I hope so). So, even without defining what a leak is, providing a tool to better create/verify filtering would be a boon. Yes, I agree! What I'd hate to see is: 4) We fully deployed BGPSEC, and RPKI, and upgraded our infrastructure, and retooled provisioning, operations and processes to support it all fully, and required our customers and peers to use it, and even then this still happened - WTF was the point? I think this is the point: https://twitter.com/#!/atoonk/status/165245731429564416 This leak thing is a key vulnerability that simply can't be brushed aside - that's the crux of my frustration with the current effort. You seem to think that there's some extension/modification to BGPSEC that would fix route leaks in addition to the ASPATH issues that BGPSEC addresses right now. Have you written this up anywhere? I would be interested to read it. --Richard
Re: Iran blocking essentially all encyrpted protocols
FWIW: A colleague in Iran was able to connect to a server in the US using HTTPS on a non-standard port (). It appears that the Iranian government is not blocking TLS/HTTPS per se, but just port 443. So in principle, if there were just some HTTPS proxies using non-standard ports, then people would be able to get out. At least until (1) the addresses of the proxies become known to the regime, or (2) they start blocking cross-border TLS altogether. --Richard On Fri, Feb 10, 2012 at 12:07 PM, Marshall Eubanks marshall.euba...@gmail.com wrote: And in response http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/ (quoting) : “Basically, say you want to look like an XMPP chat instead of SSL,” he writes to me, referring to a protocol for instant messaging as the decoy for the encrypted SSL communications. “Obfsproxy should start up, you choose XMPP, and obfsproxy should emulate XMPP to the point where even a sophisticated [deep packet inspection] device cannot find anything suspicious.” Regards Marshall On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: Yes I am from Iran and outgoing TCP/443 has been stoped ;) -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 On Feb 10, 2012, at 9:56 PM, Ryan Malayter malay...@gmail.com wrote: Haven't seen this come through on NANOG yet: http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars Can anyone with the ability confirm that TCP/443 traffic from Iran has stopped?
Re: Dear RIPE: Please don't encourage phishing
So because of phishing, nobody should send messages with URLs in them? On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin s...@cs.columbia.edu wrote: I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? --- From: ripe_dbannou...@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: [Apologies for duplicate e-mails] Dear Colleagues, We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change. Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible. To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the auth: attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the auth: field. Webupdates: https://apps.db.ripe.net/webupdates/search.html There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below. If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-...@ripe.net. (You cannot reply to this email.) Regards, Denis Walker Business Analyst RIPE NCC Database Group Referencing MNTNER objects in the RIPE Database: maint-rgnet
Re: Thanks Let's Prevent this in the Future.
In related news, the IETF working group that is writing standards for the RPKI is having an interim meeting in San Diego just after NANOG. They deliberately chose that place/time to make it easy for NANOG attendees to contribute, so comments from this community are definitely welcome. http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 On Fri, Feb 3, 2012 at 7:16 AM, Arturo Servin aser...@lacnic.net wrote: One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors. We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are signed but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/ http://www.labs.lacnic.net/rpkitools/looking_glass/ Regards, -as On 1 Feb 2012, at 06:58, Kelvin Williams wrote: First off, I'd like to thank everyone on this list who have reached out today and offered us help with our hijacked network space. It's so refreshing to see that there are still so many who refuse to leave a man/woman down. I'm not going to place any blame, its useless. There were lies, there were incompetencies, and there was negligence but that is now water under the bridge. However, I think that we as network operators have a duty to each other to make sure we don't allow a downstream customer wreck the operations of another entity who has been rightfully allocated resources. A few months ago, when establishing a new peering relationship I was encouraged (actually required) to utilize one of the IRRs. I took the time to register all of my routes, ASNs, etc. However, as I learned today, this was probably done in vain. Too many people won't spend the extra 30-seconds to verify the information listed there or in ARINs WHOIS. I don't care what a customer tells me, too many times I've found they aren't 100% honest either for malicious/fraudulent reasons or they are unknowing. So, for our networks or the networks we manage, we want to verify what a customer is saying to prevent what happened to us today. I'd like to get a conversation going and possibly some support of an initiative to spend that extra 30-seconds to verify ownership and authorization of network space to be advertised. Additionally, if someone rings your NOC's line an industry-standard process of verifying ownership and immediately responding by filtering out announcements. There's no sense in allowing a service provider to be impaired because a spammer doesn't want to give up clean IP space. Do you protect a bad customer or the Internet as a whole? I pick the Internet as a whole. How can we prevent anyone else from ever enduring this again? While we may never stop it from ever happening, spammers (that's what we got hit by today) are a dime a dozen and will do everything possible to hit an Inbox, so how can we establish a protocol to immediate mitigate the effects of an traffic-stopping advertisement? I thought registering with IRRs and up-to-date information in ARINs WHOIS was sufficient, apparently I was wrong. Not everyone respects them, but then again, they aren't very well managed (I've got several networks with antiquated information I've been unable to remove, it doesn't impair us normally, but its still there). What can we do? Better yet, how do we as a whole respond when we encounter upstream providers who refuse to look at the facts and allow another to stay down? kw -- Kelvin Williams Sr. Service Delivery Engineer Broadband Carrier Services Altus Communications Group, Inc. If you only have a hammer, you tend to see every problem as a nail. -- Abraham Maslow
Re: http://tools.ietf.org - Down
There was some discussion of this on tools-disc...@tools.ietf.org. There was a temporary issue that I believe has been resolved. --Richard On Tue, Jan 31, 2012 at 11:59 AM, Matt Taylor m...@mt.au.com wrote: Fine for me, .au Matt. On 31/01/2012 9:59 PM, Sébastien Riccio wrote: Up from here (.ch) Sébastien On 31.01.2012 10:02, Mark Tinka wrote: Is it just me? http://www.downforeveryoneorjustme.com/tools.ietf.org doesn't seem to think so. Mark. On 31/01/2012 9:59 PM, Sébastien Riccio wrote: Up from here (.ch) Sébastien On 31.01.2012 10:02, Mark Tinka wrote: Is it just me? http://www.downforeveryoneorjustme.com/tools.ietf.org doesn't seem to think so. Mark.
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
BBN has also released an initial version of their relying party software. Core features are basically the same as the other validators (namely, RPKI certificate validation), with -- more fine-grained error diagnostics and -- more robust support for the RTR protocol for distributing validated information to routers. http://www.ietf.org/mail-archive/web/sidr/current/msg03854.html On Fri, Jan 20, 2012 at 9:39 AM, Alex Band al...@ripe.net wrote: If you want to play around with RPKI Origin Validation, you can download the RIPE NCC RPKI Validator here: http://ripe.net/certification/tools-and-resources It's simple to set up and use: just unzip the package on a *NIX system, run ./bin/rpki-validator and browse to http://localhost:8080 EuroTransit have a public one running here: http://rpki01.fra2.de.euro-transit.net:8080/ You can see it's pointing to several Trust Anchors, downloads and validates all ROA periodically, you can apply ignore filters and white lists, see a BGP announcement validity preview based on route collector data, integrates with existing (RPSL based) workflows and can talk to RPKI-capable routers. If you want to get an idea of how an RPKI-capable router would be configured, here's some sample config for Cisco and Juniper: http://www.ripe.net/certification/router-configuration You can also log into a public RPKI-capable Juniper here: 193.34.50.25, 193.34.50.26 telnet username: rpki password: testbed With additional documentation available here: http://rpki01.fra2.de.euro-transit.net/documentation.html Have fun, Alex On 20 Jan 2012, at 13:08, Arturo Servin wrote: You could use RPKI and origin validation as well. We have an application that does that. http://www.labs.lacnic.net/rpkitools/looking_glass/ For example you can periodically check if your prefix is valid: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/valid/cidr/200.7.84.0/23/ If it were invalid for a possible hijack it would look like: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/200.31.18.0/24/ Or you can just query for any state: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0/22/ Regards, as On 20 Jan 2012, at 07:47, Yang Xiang wrote: Hi, I build a system ‘Argus’ to real-timely alert prefix hijackings. Argus monitors the Internet and discovers anomaly BGP updates which caused by prefix hijacking. When Argus discovers a potential prefix hijacking, it will advertise it in a very short time, both in our website (http://argus.csnet1.cs.tsinghua.edu.cn) and the mailing list (ar...@csnet1.cs.tsinghua.edu.cn). Argus has been running in the Internet for more than eight months, it usually can discover potential prefix hijackings in ten seconds after the first anomaly BGP update announced. Several hijacking alarms have been confirmed by network operators. For example: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/61544/ has been confirmed by the network operators of AS23910 and AS4538, it was a prefix hijacking caused by a mis-configuration of route filter. If you are interest in BGP security, welcome to visit our website and subscribe the mailing list. If you are interest in the system itself, you can find our paper which published in ICNP 2011 (FIST workshop) http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6089080. Hope Argus will be useful for you. _ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: Whacky Weekend: Is Internet Access a Human Right?
The analogy that occurs to me is to roads. People generally have a right of free movement, which implies that if they are capable of using roads (e.g., if they have a car and can drive it), then they should be generally free to do so, certain reasonable legal constraints notwithstanding. And in this case, the reasonableness of constraints arises from the fact that things like driving licenses and road signs are based on clear safety concerns. Mapping this over to the Internet: People generally have a right of free expression, which implies that if they are capable of using the Internet, they should be generally free to use it, certain reasonable legal constraints not withstanding. The human right in question, then, isn't a right to Internet access per se; people aren't entitled to a broadband link any more than they're entitled to live near good roads. (Note, however, that communities typically try to maintain their roads to a certain standard.) Rather, the right is to a certain *class* of Internet access, free of unnecessary constraints. The question of legal constraints and reasonableness is much thornier in this domain; you're not going to kill someone by sending them spam. (Well, maybe with SCADA systems, but we'll put that aside for now.) The obvious cases (e.g., child porn) are to some degree already covered, although there's some variation around the globe (Nazi propaganda in France). The debate over PROTECT-IP is at some level about whether and which constraints on Internet usage based on copyright constraints are reasonable. --Richard On Thu, Jan 5, 2012 at 10:22 AM, Jay Ashworth j...@baylink.com wrote: Vint Cerf says no: http://j.mp/wwL9Ip But I wonder to what degree that's dependent on how much our governments make Internet access the most practical/only practical way to interact with them. Understand: I'm not saying that FiOS should be a human right. But as a society, America's recognized for decades that you gotta have a telephone, and subsidized local/lifeline service to that extent; that sort of subsidy applies to cellular phones now as well. Thoughts? Cheers, -- jr 'yes, I know I'm early...' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Global BGP and Google
See also this: https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database Speak up if you want something similar in the ARIN or LACNIC regions. --Richard On Dec 5, 2011 5:19 PM, Andy Warner a...@andy.net wrote: On Tue, Dec 6, 2011 at 2:41 AM, Victor Esposito victorespos...@yahoo.com wrote: Has anyone had a... Maintaining IP-Geolocation mappings in inherently hard so they're not perfect. You'll probably need to update multiple IP Geolocation providers, but you can provide corrections to Google using this form: http://www.google.com/support/websearch/bin/request.py?contact_type=ip -- Andy
Re: Recent DNS attacks from China?
An attack originating from somewhere indicates the presence of either an attacker or a compromised host. A particular density of either in a particular geographical area would seem like an interesting data point. --Richard On Wed, Nov 30, 2011 at 1:24 PM, andrew.wallace andrew.wall...@rocketmail.com wrote: Before we see knee-jerk conclusions about who to blame, these attacks could be carried out by anyone. Is country even relevant in the cyberscape? Andrew From: Leland Vandervort lel...@taranta.discpro.org To: nanog@nanog.org Cc: Leland Vandervort lel...@taranta.discpro.org Sent: Wednesday, November 30, 2011 4:32 PM Subject: Recent DNS attacks from China? Hi All, I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. Anyone else? Regards, Leland
Re: Historical records of IP allocations
Sounds like a good application for INRDB: https://labs.ripe.net/Members/kistel/content-intro-inrdb-internet-number-resource-database RIPEstat also has at least its routing history, back as far as 2006: http://stat.ripe.net/109.190.0.0/17 On Sun, Nov 6, 2011 at 7:01 PM, Louis P lbstrea...@gmail.com wrote: Hello, Does anyone know if it's possible to get old records (AS numbers...) of an IP allocation ? I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ But only the country and allocation date are included. The IP range I would like to have more information about is 109.190.0.0/17 (it was Russian before and now French). Thanks in advance, Regards, Louis P.
Re: using IPv6 address block across multiple locations
Couldn't you also advertise the /48 from all the sites, if you're willing to sort things out over the inter-site VPNs?--Richard On Mon, Oct 31, 2011 at 4:37 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Don't expect anyone to accept less than /48, so in your setup you need a /48 per site. -- Mikael Abrahamsson email: swm...@swm.pp.se
Re: meeting network
Problem for me at least has not been the MAC layer (either hotel room or meeting room), it was that the DHCP server was not responding. Ironically, I could still see everyone's Bonjour and SMB service advertisements. --Richard On Mon, Oct 10, 2011 at 8:46 AM, Nick Hilliard n...@foobar.org wrote: On 10/10/2011 13:28, Randy Bush wrote: perhaps as an educational exercise in network troubleshooting whoever is operating the meeting network could explain what the frack is wrong with the meeting network, how it is being debugged, and what they have learned about the cause of the suckage. if it's wifi that's causing the trouble, the usual causes are: - insufficient density of APs for the number of clients - APs configured with TX too high (should be set as low as possible) - APs configured to accept dot11b = 9 megs - APs configured to use auto channel selection - stupid broken clients screaming at high volume across the room to APs which are impossibly far away There is a more fundamental problem, though: wifi was not designed with crazyass density in mind. Bring back UTP? Nick
Re: meeting network
VPN traffic was also slow / bursty. So I guess there's some capacity issues as well as layer 7 cruft. On Oct 10, 2011 10:20 AM, Randy Carpenter rcar...@network1.net wrote: On the hotel network, I have also seen some issues beyond getting an address. I can usually trace just fine, but applications, specifically web is extremely slow, or non responsive. The hotel appears to be shoving all traffic through a squid proxy, which does not appear to be big enough to handle the traffic. I have gotten various error messages from squid. I would think that the contract with the hotel for the conference would include the specific requirements for the network. Is that not the case? -Randy On Oct 10, 2011, at 10:01, Owen DeLong o...@delong.com wrote: On Oct 10, 2011, at 6:50 AM, ...
Re: Botnets buying up IPv4 address space
If not short-lived, then at least self-limiting. --Richard On Fri, Oct 7, 2011 at 3:15 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Oct 7, 2011 at 3:10 PM, Arturo Servin arturo.ser...@gmail.com wrote: I agree with Benson. In fact, for this problem I find irrelevant that IPv4 is running out. They are just looking for good reputation IP nodes. isn't this a short-lived problem then?
Re: Internet mauled by bears
And if they turn up the voltage on the fence high enough, dinner could be cooked by the time the crew gets there! On Sep 19, 2011 9:34 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen jvanop...@spectrumnet.us wrote: We had a cow br... Your crews turning up there the next time a cow tries its luck are guaranteed a steak dinner then. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)
There's an app^W^Wa Working Group for that. http://tools.ietf.org/wg/dane/ On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones m...@mikejones.in wrote: On 11 September 2011 16:55, Bjørn Mork bj...@mork.no wrote: You can rewrite that: Trust is the CA business. Trust has a price. If the CA is not trusted, the price increases. Yes, they may end up out of business because of that price jump, but you should not neglect the fact that trust is for sale here. The CA model is fundamentally flawed in the fact that you have CAs whose sole trustworthiness is the fact that they paid for an audit (for Microsoft, lower requirements for others), they then issue intermediate certificates to other companies (many web hosts and other minor companies have them) whose sole trustworthiness is the fact that they paid for an intermediate certificate, all of those companies/organisations/people are then considered trustworthy enough to confirm the identity of my web server despite the fact that none of them have any connection at all to me or my website. There is already a chain of trust down the DNS tree, if that is compromised then my SSL is already compromised (if they control my domain, they can verify they are me and get a certificate), what happened to RFC4398 and other such proposals? EV certificates have a different status and probably still need the CA model, however with standard SSL certificates the only validation done these days is checking someone has control over the domain. DNSSEC deployment is advanced enough now to do that automatically at the client. We just need browsers to start checking for certificates in DNS when making a HTTPS connection (and if one is found do client side DNSSEC validation - I don't trust my ISPs DNS servers to validate something like that, considering they are the ones likely to be intercepting my connections in the first place!). It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it? - Mike
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
Looks like the RIS collectors are seeing it originating mostly from STC and KACST ASNs: http://stat.ripe.net/212.118.142.0/24 Some of the show ip bgp reports on that screen are also showing AS8866 BTC-AS Bulgarian Telecommunication Company. Not sure what's up with that. --Richard On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren pixitha.k...@gmail.com wrote: Is this announcement still showing up this way (no easy way to check myself). ripe ris? -Kyle On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes chay...@centracomm.net wrote: On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) j...@probe-networks.de wrote: Hello, anyone else getting a route for 212.118.142.0/24 with invalid attributes? Seems this is (again) causing problems with some (older) routers/software. Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1 6-Resolve tree 2 AS path: 6453 39386 25019 I Unrecognized Attributes: 39 bytes AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04 00 00 00 64 Accepted Multipath -Jonas Yup! We're seeing the same thing too, and we're filtering it out. Originating AS is 25019 -Clay
Re: Errant Advertisement - 128.1/16
Plus, technically, since symbolics.com was non-operational for a while, bbn.com is the oldest .com domain in continuous operation. And you'll notice that it has IPv6-reachable web and DNS servers :) On Mon, Aug 8, 2011 at 11:29 AM, Peter Stockli pete...@gmail.com wrote: Wow, BBN, the reason we use the @ sign, second .com Domain, former AS1. Lots of history ;) On Mon, Aug 8, 2011 at 2:07 PM, Rick Altmann raltm...@bbn.com wrote: This issue has been cleared up. Thanks to everyone for their help. -Rick On Aug 4, 2011, at 12:07 PM, Rick Altmann wrote: Is there anyone from ATT on the list that could help with a likely misconfiguration? I have not received any response yet to my complaint (see below) submitted to the abuse address on July 26. We have since started advertising this space and would like to resolve the MOAS condition we have created. The 128.1.0.0/16 address block is registered to BBN Technologies (AS11488) but is currently unused on any BBN networks. BBN would like to begin using this address space however AS7018 is currently originating public BGP routes for this address block. We believe this to be a configuration error. Please help us resolve this. A traceroute to 128.1.0.1 shows the following routers as the last 4 responding hops: cr1.n54ny.ip.att.net (12.122.81.106) cr81.nw2nj.ip.att.net (12.122.105.30) gar18.n54ny.ip.att.net (12.122.105.101) 12.89.231.190 Thanks, Rick
Re: unqualified domains, was ICANN to allow commercial gTLDs
The same type that Colombia/NeuStar is doing with .co? On Sun, Jun 19, 2011 at 2:49 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Randy Bush ra...@psg.com said: Now I'm tempted to be the guy that gets .mail express that temptation in dollars, and well into two commas. Imagine the typo-squating someone could do with .con. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Re: v6 Avian Carriers?
Be careful what you wish for: http://tools.ietf.org/html/draft-ymbk-aplusp On Fri, Apr 1, 2011 at 6:47 PM, Dorn Hetzel d...@hetzel.org wrote: I was thinking today would be a good day to write an RFC for fractional DHCP where end-users can get issued say 1/64 of an v4 IP, say 155.229.10.20:1024-2047. Other users on the same DSLAM, etc behind the carrier NAT would have other shares of the same public IP. :) On Fri, Apr 1, 2011 at 12:19 PM, Brandon Ross br...@pobox.com wrote: On Fri, 1 Apr 2011, GP Wooden wrote: I wonder on the carrier would survive a DoS attack ... I'm not sure about that, but we know that, if a Sullenberger unit has been installed, a large aircraft can survive a DoS attack perpetrated by the avian carrier. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: The state-level attack on the SSL CA security model
Which is especially funny since Comodo is citing the fact that they've had no OCSP requests for the bad certs as evidence that they haven't been used. --Richard On Thu, Mar 24, 2011 at 10:53 AM, Tony Finch d...@dotat.at wrote: Harald Koch c...@pobox.com wrote: This story strikes me as a success - the certs were revoked immediately, and it took a surprisingly short amount of time for security fixes to appear all over the place. It would have been much easier if certificate revocation actually worked properly. http://www.imperialviolet.org/2011/03/18/revocation.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking, North Utsire, South Utsire: Westerly veering northerly, 4 or 5, occasionally 6 at first. Moderate or rough. Occasional rain. Moderate or good, occasionally poor at first.
Re: Interesting google redirects.
What networks are the affected clients on? On Thu, Mar 3, 2011 at 10:53 AM, Skywing skyw...@valhallalegends.com wrote: (Apologies for the top-post.) I've been experiencing the same. Seems like their geolocation data is busted (since last morning at least), if I had to take a guess. - S -Original Message- From: Wil Schultz wschu...@bsdboy.com Sent: Thursday, March 03, 2011 7:25 To: NANOG Operators Group nanog@nanog.org Subject: Interesting google redirects. Has anyone else had complaints that www.google.com is occasionally redirecting (http 302) to www.google.com.hk this morning? -wil
Re: Mac OS X 10.7, still no DHCPv6
Anyone care to start the IPv4 dead pool, Price is Right style, for when the last v4 NLRI is removed from the DFZ? That's funny, I don't care what galaxy you're from :) So that puts your bet at more than 25,000 years? http://en.wikipedia.org/wiki/Canis_Major_Dwarf_Galaxy
Re: Mac OS X 10.7, still no DHCPv6
In fairness, said device can do the same sort of inspection of SLAAC traffic. It just looks at neighbor discovery messages instead of DHCP messages. http://tools.ietf.org/html/draft-ietf-savi-fcfs On Sun, Feb 27, 2011 at 2:17 PM, Leigh Porter leigh.por...@ukbroadband.com wrote: On 27 Feb 2011, at 19:07, Antonio Querubin wrote: On Sun, 27 Feb 2011, Mikael Abrahamsson wrote: On Sun, 27 Feb 2011, Leigh Porter wrote: Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment? You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't get an IPv6 address, it takes one. This is often required for legislation compliance. DHCP does this well. Which is one of the reasons why some of us want DHCPv6 support in hosts. So how does DHCP prevent a host from just taking or hijacking an IP address? Antonio Querubin e-mail/xmpp: t...@lava.net You can have devices that peek at the DHCP messages and then open filters so that you at least know that any host that pops up on the network has used DHCP to obtain an IP address. Now you cannot usually prevent somebody from later hijacking that IP address using a fake MAC unless you do something else as well but at least you have something of a statefull relationship between an host and the IP address it uses. -- Leigh Porter
Re: Mac OS X 10.7, still no DHCPv6
In fairness, said device can do the same sort of inspection of SLAAC traffic. It just looks at neighbor discovery messages instead of DHCP messages. http://tools.ietf.org/html/draft-ietf-savi-fcfs Any known (existing) or planned implementations of this? None that you can buy off the shelf. I understand that Tsinghua University in Beijing has prototype code running on several types of switches.
Re: 123.45.67.89
Looks like that's in a CEGETEL dynamic pool in France. Maybe you should sign up for their service? http://albatross.ripe.net/cgi-bin/rex.pl?type=allres=86.75.30.9/32stime=2010-02-17etime=2011-02-17page=holdercf=1af=1 On Fri, Feb 18, 2011 at 12:01 PM, Matlock, Kenneth L matlo...@exempla.org wrote: I'm not sure what all I'd do with it (besides have the hostname 'Jenny'), but I'd love to have 86.75.30.9 Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: Robert Lusby [mailto:nano...@gmail.com] Sent: Friday, February 18, 2011 9:48 AM To: nanog@nanog.org Subject: 123.45.67.89 --- Friday miscellaneous --- What can anyone tell me about IPv4: 123.45.67.89 ? Other than it's used by Samsung in Korea? Do they have any cool applications for it? Do you have, or know of any other cherished IPv4s? What do you use it for? Google DNS is a good example (4.4.4.4).
Re: NYTimes: Egypt Leaders Found ‘Off’ Switch for Internet
Never mind, Messrs. Cowie and Baker answered my question: http://mailman.nanog.org/pipermail/nanog/2011-February/033181.html Couldn't have paths through Egypt if layer 2 were cut off. (Right?) --Richard On Wed, Feb 16, 2011 at 5:38 PM, Richard Barnes richard.bar...@gmail.com wrote: It also seems like a question that could be decided empirically. Can anyone on here comment on whether or not the BGP session ended gracefully and the link lights remained lit? --Richard On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks t...@americafree.tv wrote: On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: http://www.nytimes.com/2011/02/16/technology/16internet.html There has been intense debate both inside and outside Egypt on whether the cutoff at 26 Ramses Street was accomplished by surgically tampering with the software mechanism that defines how networks at the core of the Internet communicate with one another, or by a blunt approach: simply cutting off the power to the router computers that connect Egypt to the outside world. I do remember some intense debate, here and elsewhere, but I somehow don't remember those as being the primary debate parameters. Regards Marshall -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org ---
Re: My upstream ISP does not support IPv6
This seems ironic, given the number of ISPs I've heard say There's no customer demand. --Richard On Thu, Feb 3, 2011 at 10:04 PM, Franck Martin fra...@genius.com wrote: The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. Is that bull? I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? It seems to me the typical answer sales people say when asked about IPv6: Gosh, this is the first time I'm asked this one.
Re: ipv4's last graph
Note that the ARIN, APNIC, and RIPE lines should all basically level out to asymptotes after they hit 1 /8 left, due to the soft run out policies in place [1][2][3]. Either that, or just consider arriving at 1 /8 left as depletion. Geoff: How are your graphs dealing with these policies? [1] https://www.arin.net/policy/nrpm.html#four10 [2] http://www.apnic.net/policy/add-manage-policy#9.10.1 [3] http://ripe.net/ripe/policies/proposals/2010-02.html On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain alh-i...@tndh.net wrote: -Original Message- From: Vincent Hoffman [mailto:jh...@unsane.co.uk] Sent: Wednesday, February 02, 2011 9:44 AM To: nanog@nanog.org Subject: Re: ipv4's last graph On 02/02/2011 17:22, Matthew Petach wrote: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools-zoom.pdf works for me without needing to download a pdf viewer For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg Vince 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? I thought about leaving it off completely, but figured I would be asked for scale. It is /8's remaining until they drop into their 'last allocation' policy. I will see if I can figure out how to fit that into something readable. But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Geoff has always been the optimist ... ;0 Matt
Re: APNIC description: unknown
Some times they're not so anonymous :) 122.200.40.0/21 38272 UNKNOWN http://122.200.40.5/ Sonargaon Online Limited(SOL) is the leading Internet Service Provider in Dhaka http://122.200.40.5/pages/contact_us.htm 40/1, Rahman Plaza Shahid Faruk Road (4th Floor) Jatrabari, Dhaka Bangladesh Tel : 88-02-7553432 E-mail : i...@sonargaononline.net On Mon, Jan 31, 2011 at 10:00 PM, Owen DeLong o...@delong.com wrote: On Jan 31, 2011, at 6:32 PM, Vovan wrote: Hello, sorry for possibly trite question, but what does this UNKNOWN mean? e.g.: Network Origin AS Description 41.222.79.0/24 36938 UNKNOWN quote from: http://thyme.rand.apnic.net/current/data-add-IANA Cheers, Vladimir It's an unallocated address being advertised by an unallocated AS number. Pretty hard to identify a contact for such a route, no? Owen
Re: [arin-announce] ARIN Resource Certification Update
It's in-band only in the sense of delivery. The worst that a corruption of the underlying network can do to you is deny you updates; it can't convince you that a route validates when it shouldn't. And even denying updates to your RPKI cache isn't that bad, since the update process doesn't really need to be real-time. Things will stay the same until you start hitting expiration times. The ultimate worst case is that everything expires and there are no RPKI-validated routes ... just like today. --Richard On Mon, Jan 24, 2011 at 9:11 PM, Roland Dobbins rdobb...@arbor.net wrote: On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote: I just don't like the notion of deploying a brand new system with data that at the end of the day is going to look an awful lot like the existing in-addr.arpa delegation system that's deployed, and introduce new hierarchical shared dependencies that don't exist today. Right - so, the macro point here is that in order to make use of rPKI so as to ensure the integrity of the global routing system, the presupposition is that there's already sufficient integrity in said routing global system for the rPKI tree to be successfully walked in the first place, given that it's all in-band, right? And since it's all in-band, anyways, with the recursive dependencies that implies, why not make use of another, pre-existing inband hierarchical system which is explicitly designed to ensure the integrity of its answers, and which is already in the initial stages of its deployment - i.e., DNSSEC? Note I'm not advocating this position, per se, just being sure I understand the argument for purposes of discussion. 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-announce] ARIN Resource Certification Update
On Mon, Jan 24, 2011 at 9:16 PM, Danny McPherson da...@tcb.net wrote: On Jan 24, 2011, at 9:02 PM, Joe Abley wrote: In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and hence no opportunity for them to indicate the legitimacy of the allocation. As a thought experiment, how would you see this working? New prefix-based RRs? And perhaps even a new .arpa or in-addr.arpa subdomain, the draft Randy referenced even discussed the latter, IIRC. -danny The more you have to invent, though, the more this sounds like a bike-shed discussion. s/DNSSEC/X.509/g s/delegating reverse prefix zone/signing RPKI delegation certificate/g
IPv6 prefix lengths
Hi all, What IPv6 prefix lengths are people accepting in BGP from peers/customers? My employer just got a /48 allocation from ARIN, and we're trying to figure out how to support multiple end sites out of this (probably around 10). I was thinking about assigning a /56 per site, but looking at the BGP table stats on potaroo.net [1], it looks like this is not too common (only .29% of prefixes). Thoughts? Thanks, --Richard [1] http://bgp.potaroo.net/v6/as2.0/index.html
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: 2010 IPv4 (and IPv6) Address Use Report
Also, for a slightly more average-person-friendly view, see Iljitsch's article in Ars Technica: http://arstechnica.com/tech-policy/news/2011/01/2010-in-ip-addresses-225-million-down-496-million-to-go.ars On Tue, Jan 4, 2011 at 6:29 AM, Iljitsch van Beijnum iljit...@muada.com wrote: [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status reserved. 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are reserved for future use. With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a reserved address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The IANA global pool consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the allocated and legacy categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each administered by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use emreally/em takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people no before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what
Re: 2010 IPv4 (and IPv6) Address Use Report
Certainly not. I was thinking more if people wanted something to pass on to management, marketing, mother, etc --Richard On Tue, Jan 4, 2011 at 12:21 PM, Iljitsch van Beijnum iljit...@muada.com wrote: On 4 jan 2011, at 17:30, Richard Barnes wrote: Also, for a slightly more average-person-friendly view, see Iljitsch's article in Ars Technica: http://arstechnica.com/tech-policy/news/2011/01/2010-in-ip-addresses-225-million-down-496-million-to-go.ars I would never dare call NANOG members average. :-) Iljitsch
Re: Wireless IPv6
FWIW, the same does not appear to be true of the Verizon 3G network. (Not that anyone expected it to be.) My VZW device has a NATted v4 address and only link-local v6. On Dec 28, 2010 1:26 PM, Cameron Byrne cb.li...@gmail.com wrote: On Tue, Dec 28, 2010 at 10:15 AM, valdis.kletni...@vt.edu wrote: On Tue, 28 Dec 2010 12:49:37 E... Just to update the group, a helpful person sent me a screenshot of the VZW LTE connection manager, and it does indeed have a public IPv6 address an a 10.x.x.x IPv4 address. So, true to claim, the new LTE service available today on USB sticks is production dual-stack. Bravo! Cameron == http://groups.google.com/group/tmoipv6beta ==
Re: wikileaks dns (was Re: Blocking International DNS)
Other possible solution would be a DNSarchive, in the same way there is a WebArchive. Any volunteer? The RIPE REX tool provides something like this, at least for the reverse tree. http://rex.ripe.net/ http://albatross.ripe.net/cgi-bin/rex.pl?type=allres=213.251.145.0/24stime=2009-12-02etime=2010-12-02page=dnscf=1af=1 Of course, it appears that none of the three cabelgate IP addresses you cite have reverse records provisioned that point to wikileaks (just bahnhof.se and ovh.net). --Richard
Re: CAP / WARN / iPAWS
There is also some work in the IETF on the more general problem of distributing early warning messages: http://tools.ietf.org/wg/atoca Right now, they're taking a pretty layer-7 approach (distributing CAP in SIP messages), but part of their charter is figuring out how this application relates to things like iPAWS, CMAS, 3GPP PWS, etc. So they will likely end up looking at some layer-2/3 aspects of the problem as well. --Richard On Thu, Dec 2, 2010 at 4:42 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Jack Bates jba...@brightok.net What would be really awesome (unless I've missed it) is Internet access to the emergency broadcast system and local weather services; all easily handled with multicast. Ah, something I know something about for a change. :-) In fact, there's some work in progress on this topic, Jack; FEMA is working on replacing the EAS -- which itself replaced EBS, and earlier, Conelrad -- with a new system called iPAWS: The Integrated Public Alert and Warning System. At the moment, they're working on the replace the EAS backbone part of it, which work is about a year behind schedule, and everyone wants an extension, but there are other useful places to apply some effort. I'm a designer, not a coder, so I've been piddling around in the part I'm good at; thinking about design. Some of the results are here: http://www.incident.com/cookbook/index.php/Rough_consensus_and_running_code and http://www.incident.com/cookbook/index.php/Alerting_And_Readiness_Framework and I invite off-list email from anyone who has suggestions to toss in the pot. Cheers, -- jra (I would like to subject-unthread this, but my mailer is too stupid. Sorry)
Re: Online games stealing your bandwidth
BitTorrent have been active contributors to the IETF LEDBAT working group, which is looking at transport protocols that back off much more aggressively than TCP, with exactly the idea of making P2P have a lower impact on other things at the customer edge. http://tools.ietf.org/wg/ledbat/ On Tue, Sep 28, 2010 at 9:58 AM, Jack Bates jba...@brightok.net wrote: On 9/27/2010 7:35 PM, Warren Bailey wrote: Can someone name an ISP that encourages P2P traffic?? ;) A proper ISP doesn't encourage any type of traffic. We're indifferent. Of course, we'll be happy to mention the benefits and draw backs of using various protocols on the Internet. Demand wise, video streaming to point and click boxes will load the network far more than p2p ever has; granted, in the opposite direction of the normal p2p complaint. My, and my company's, biggest complaint is the lack of improvement on these protocols to play more friendly with customer's other traffic. It is not so much the effects of it on my network, as much as how it effects my customer's unshared link. The give me everything tactic, especially on outbound traffic, saturates the link, which in turn lowers the customer's other traffic. Am I the only one who likes to stream video while running bittorrent, surfing the web, checking my email, and playing some online game all at the same time? I'm not going to rag on bittorrent, though. I do have adjustments in my clients to cap the upstream/downstream to allow my other traffic through. Many clients and protocols don't have this ability, though. Some purposefully hide themselves and what they are doing. The only indication is the fact that the Internet is slow. The people who make this software should sit in a call center troubleshooting why The Internet is slow! when various software products are bandwidth hogs (and sometimes are hidden from the customer completely). We, of course, detect the link saturation, but there is no indicator for us to help the customer figure out what they need to disable. Jack
Re: ip block history.
RIPE has been developing a couple of projects to support this sort of history searching: Internet Resource Database (INRDB): http://labs.ripe.net/Members/kistel/content-intro-inrdb-internet-number-resource-database Resource EXplainer (REX): http://rex.ripe.net/ On Tue, Sep 14, 2010 at 5:46 PM, Greg Whynott greg.whyn...@oicr.on.ca wrote: Thanks for the pointers Joel! google knows all, scary isn't it? -g On Sep 14, 2010, at 5:01 PM, Joel Jaeggli wrote: assuming the whois data has been cleaned up the next resource to look at is: routeviews or ris table dumps to see where or if it was advertised in the past, and from where. google and rbl lists are also worth querying in that context. joel On 9/14/10 1:51 PM, Greg Whynott wrote: probably an odd question … we have been assigned a few large blocks of IPs, and while configuring BGP i got to wondering what these block's history might be. who had them in the past, etc.. is there a publicly accessible db or similar which tracks that type of information, or is that liability concern? thanks! greg
Re: IP characteristics for 3G and WiFi links
On Thu, Aug 26, 2010 at 6:26 AM, Daniel Migault mglt@gmail.com wrote: Hi, We are testing protocols on our lab platform and we would like to simulate communication 2 types of communication : - From terminals to service platform using a 3G (HSPA / HSPA+) Access connection - From terminal to service platform using a WiFi Access connection We are using dummyNet to simulate the links so we are interested in IP characteristics layers for Packet loss Rate, bandwidth and latency. Values depends on multiple factors, but we would like to know what mean values are considered when services are deployed. Currently we are considering the following values. Packet Lost Rate for L2 seems 7% for Wifi and 5% for 3G. We are wondering how L3 is affected? Parameter | Wifi (802.11a/g) | 3G (HSDPA) Latency 100 ms 60 ms Bandwidth 5 Mbps 3 Mbps Packet Lost Rate XXX XXX Any comment links will be appreciated. Regards, Daniel -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58
Re: Inquiries to Acquire IPs
Maybe APNIC should give him 1.1.1.1 and see how he likes it! On Fri, Jul 2, 2010 at 3:33 PM, Jess Kitchen jess.kitc...@adjacentnetworks.net wrote: On Fri, 2 Jul 2010, Kevin Stange wrote: Hello, According to Whois data, you company owns the following IP address space: 206.220.220.0/24 146.6.6.0/24 Anyone else notice they seem to be looking for IP blocks where the middle octets are the same? How could that specific quality be worth $5K? They are vanity IPs for use with an anycast DNS service
Re: The Economist, cyber war issue
Apparently the Economist has just become aware of the coming 8-bit apocalypse: http://www.youtube.com/watch?v=yGeuiZr-u50 On Thu, Jul 1, 2010 at 9:25 AM, Gadi Evron g...@linuxbox.org wrote: The upcoming issue will be about cyber war. Check out the front page image: http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs488.snc3/26668_410367784059_6013004059_4296972_499550_n.jpg Gadi.
Re: ATT BGP - Advertising my network on accident
So, as periodically happens to me, what started as an idle curiosity turned into an experiment. I took a look at a RIB snapshot from Friday, from one of the RouteViews collectors, to see how common it is that a block gets advertised by two different ASes, as a whole block by one, and as a set of smaller blocks by the other. It turns out there's a non-trivial amount out there -- 490 blocks broken up, adding 1,815 prefixes announced, accounting for 19,623 RIB entries. More details below; let me know if you're interested in even more. Seems kind of interesting, as a form of deaggregation that doesn't show up in things like the CIDR report (since it's not within a single AS). (Standard caveats apply: This is a quick pass, not controlled for things like two ASes belonging to the same entity.) --Richard Total number of deaggregated prefixes: 490 Total additional prefixes advertised: 1815 Total additional RIB entries: 19623 (0.5% out of 3530845 total entries) Total addresses affected: 78863360 (roughly 1,203 /16s) Extremal points: 1. Largest deaggregated block: 17.0.0.0/8, advertised by AS7018 (ATT), deaggregated into two /9s by AS714 (Apple Engineering) 2. Most fractured block: 58.140.0.0/14, advertised by AS3786 (LG DACOM, KR), deaggregated into 69 prefixes (ranging from /17 to /24) by AS10036 (CM Communication, KR). Distribution of the number of additional prefixes: Prefixes Count 2343 3 13 4 80 5 5 6 1 7 4 8 17 9 5 10 1 11 1 14 1 15 1 16 6 17 1 20 2 32 7 34 1 69 1 Distribution of prefix lengths deaggregated: Len Count 8 1 11 1 12 3 13 9 14 17 15 22 16 47 17 25 18 29 19 65 20 52 21 56 22 69 23 92 24 2 Distribution of the number of addresses affected: Addresses Count 512 2 102492 204869 409656 819252 1638465 3276829 6553625 13107247 26214422 52428817 1048576 9 2097152 3 4194304 1 33554432 1
Re: ATT BGP - Advertising my network on accident
I wonder how much of the de-aggregation in the routing table is attributable to issues like this? On Fri, Jun 25, 2010 at 9:56 AM, Eric Williams ewilli...@connectria.com wrote: This issue has been resolved by breaking up the /22 into /24's. Thanks to all for the advise. Maybe next time I will take someone's advise and advertise one of ATT's /8's. From: Eric Williams/Connectria To: nanog@nanog.org Date: 06/24/2010 02:37 PM Subject: ATT BGP - Advertising my network on accident ATT is currently advertising my address space to the internet accidentally via BGP which they should not be. Since they are advertising my address space on accident, we are dead in the water. Does anybody out there work for ATT or know of the number I can call in order to have them stop advertising my /22 ASAP
Re: DNS performance...
OARC did a performance study of a few name servers in the context of root zone scaling, but it should be generalizable: http://www.ripe.net/ripe/meetings/ripe-59/presentations/wessels-root-zone.pdf On Wed, May 5, 2010 at 4:41 PM, Donald Eastlake d3e...@gmail.com wrote: Hi, There are a large number of DNS servers available. See for example http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software Does anyone know of good performance comparisons, especially for high end applications with lots of data/zones and/or high query/update rates? Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com
Re: DNS performance...
... and here's the direct link to the full report: https://www.dns-oarc.net/files/rzaia/rzaia_report.pdf On Wed, May 5, 2010 at 4:48 PM, Richard Barnes richard.bar...@gmail.com wrote: OARC did a performance study of a few name servers in the context of root zone scaling, but it should be generalizable: http://www.ripe.net/ripe/meetings/ripe-59/presentations/wessels-root-zone.pdf On Wed, May 5, 2010 at 4:41 PM, Donald Eastlake d3e...@gmail.com wrote: Hi, There are a large number of DNS servers available. See for example http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software Does anyone know of good performance comparisons, especially for high end applications with lots of data/zones and/or high query/update rates? Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com
Re: [Nanog] Re: IPv6 rDNS - how will it be done?
Naïve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem? On Tue, Apr 27, 2010 at 8:47 PM, Jason 'XenoPhage' Frisvold xenoph...@godshell.com wrote: On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite. Is DDNS really considered to be the end-all answer for this? It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added. Alternatively you can delegate the reverse for the /48 to servers run by the customers. This works for commercial customers, but I'm not sure I'd want to delegate this to a residential customer. Mark --- Jason 'XenoPhage' Frisvold xenoph...@godshell.com --- Any sufficiently advanced magic is indistinguishable from technology. - Niven's Inverse of Clarke's Third Law
Re: [Nanog] Re: IPv6 rDNS - how will it be done?
off-topic IANADBExpert Interesting theory, but seems kind of wrong. Wouldn't the time to look up or fail be tied to the complexity of how the key space is populated? In any case, it seems like the time to succeed or fail will usually be about the same, since you'll try to access the value for a key and either find something there or fail. On Tue, Apr 27, 2010 at 9:19 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/27/2010 19:50, Richard Barnes wrote: Naďve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem? If you get a request, you will have to respond in any case. I have a theory about data-base lookups--finding something is always faster than not finding anything, unless you are using a human brain. (A human brain can respond I don't know that without an inventory of everything it does know.) (That may be to only truly unique thing about humans. And no, I have not kept up with neural networks work.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: [Nanog] Re: IPv6 rDNS - how will it be done?
Presumably, if you've already got a script that's provisioning reverse results, you could amend it to add name constraints. No idea if this is possible with current DynDNS software, though. --Richard On Tue, Apr 27, 2010 at 9:10 PM, Jason 'XenoPhage' Frisvold xenoph...@godshell.com wrote: On Apr 27, 2010, at 9:00 PM, David Conrad wrote: Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-). Um.. sure. :) Your computer can't handle that? How about a programmatic expansion? Only create the necessary record when asked for it. Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded DNSSEC curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes. DNSSEC does seem to throw the proverbial wrench in the works.. At least, from what I understand.. I'm still not sold on DNSSEC and that, partly, has to do with a lack of knowledge.. If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ? Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically? Regards, -drc --- Jason 'XenoPhage' Frisvold xenoph...@godshell.com --- Any sufficiently advanced magic is indistinguishable from technology. - Niven's Inverse of Clarke's Third Law
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Isn't global addresses you can take with you when you change providers kind of the definition of Provider Independent address space? If you want to keep the same addresses when you change providers, you just need to get a PI allocation. --Richard On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). So what happens when you change providers? How are you going to keep using globals that now aren't yours? I'm also curious about these headaches. What are they? -Chris
Re: Posting from freebie E-mail Accounts
+1 On Wed, Mar 31, 2010 at 12:00 AM, jim deleskie deles...@gmail.com wrote: I'm betting more then a few of use free mail accts to keep this separate from our work mail. If your really having that much issue, config your mail server to drop it yourself or unsub Seriously -jim yes posted from gmail acct. On Wed, Mar 31, 2010 at 12:42 AM, Andrew D Kirch trel...@trelane.net wrote: Is there anyone here who is legitimate using a freebie webmail account? I am proposing that the NANOG administration drop everything originating from commonly used webmail providers, and add further RHS filters as additional providers are identified as problems. Andrew
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Actually, it's 31,800 CHF == 30,170 USD. Plus, you have to get the approval of your local government even to submit an application. http://www.itu.int/members/sectmem/Form.pdf On Wed, Mar 31, 2010 at 6:15 PM, Owen DeLong o...@delong.com wrote: On Mar 31, 2010, at 12:18 PM, David Conrad wrote: On Mar 31, 2010, at 6:52 AM, Joly MacFie wrote: On Tue, Mar 30, 2010 at 8:15 PM, David Conrad d...@virtualized.org wrote: Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. Quite annoying, actually. Why isn't this on YouTube? You'd have to ask the ITU secretariat. I'd note that they do audiocast meetings such as this, however you have to have a TIES account to gain access to it. Not sure how one would go about getting a TIES account. Regards, -drc $20,000/year to the ITU secretariat to become a sector member. Owen
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
There were a few representatives of the Internet community at the meeting. All five RIRs were represented, as was ISOC. The notable absence was ICANN. Of course, this sample is by no means representative of the entire community, but it's more than None. On Tue, Mar 30, 2010 at 7:50 PM, Martin Hannigan mar...@theicelandguy.com wrote: None. On 3/11/10, Eric Brunner-Williams brun...@nic-naa.net wrote: What NANOG contributors, if any, are invited by a government, to join their national delegation to the initial meeting of the ITU's IPv6 Group in Geneva next week? -- Sent from my mobile device Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd)
Care to explain what that could possibly be? (I simply don't see an upside to making it easy to censor the internet by national identity). Maintenance of GeoIP-databases becomes easier and less error-prone ? Possible less out of date because of it. We've seen complaints about those many times on this list. There are much better ways to handle geolocation than reconfiguring the structure of the IP address space. See also: http://tools.ietf.org/wg/geopriv/ http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery http://tools.ietf.org/html/draft-ietf-geopriv-held-identity-extensions Regardless of the technical merits of those specific protocols, which have been debated here and elsewhere, geolocation is an application-layer concept, and shouldn't be forced down onto the network layer. --Richard
Re: Email Portability Approved by Knesset Committee
Dude, think to the future -- /128s! On Mon, Feb 22, 2010 at 3:03 PM, Hank Nussbacher h...@efes.iucc.ac.il wrote: On Mon, 22 Feb 2010, Dorn Hetzel wrote: I am sure the various carriers faced with the onset of Local Number Portability and WLNP in this part of the world would have been happy to escape with only forwarding phone calls for 3 months. Alas, such was not their fate :) I would watch out for this idea, it might actually catch on in various places, warts and all... Can IP number portability be far behind? You think your routing tables are big now?! Wait till you are mandated to carry /32s for IP number portability :-) -Hank
Re: Comcast IPv6 Trials
What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with 1 IP address (e.g., for user data / control of the cable box). On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman ober...@es.net wrote: Date: Wed, 27 Jan 2010 20:59:16 -0800 From: George Bonser gbon...@seven.com -Original Message- From: William McCall Sent: Wednesday, January 27, 2010 7:51 PM Subject: Re: Comcast IPv6 Trials Saw this today too. This is a good step forward for adoption. Without going too far, what was the driving factor/selling point to moving towards this trial? SWAG: Comcast is a mobile operator. At some point NAT becomes very expensive for mobile devices and it makes sense to use IPv6 where you don't need to do NAT. Once you deploy v6 on your mobile net, it is to your advantage to have the stuff your mobile devices connect to also be v6. Do do THAT your network needs to transport v6 and once your net is ipv6 enabled, there is no reason not to leverage that capability to the rest of your network. /SWAG My gut instinct says that mobile operators will be a major player in v6 adoption. SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and Internet provider, but they don't do mobile (so far). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Countries with the most botnets
Team Cymru seems to put out a lot of information in their newsletters about where bots are, e.g. this article about the locations of botnet controllers: http://www.team-cymru.org/ReadingRoom/Articles/botnet-cnc-tlds-and-countries.html On Wed, Jan 27, 2010 at 6:07 PM, Steven Bellovin s...@cs.columbia.edu wrote: A colleague needs to know, along with citable sources if possible. Ideally - number of zombified PCs, percentage of zombified PCs, name of nation, source. Threat reports from symantec and macafee suggest the US leads, with China a very close second. Yes, we realize that answers will be imperfect. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: 1/8 and 27/8 allocated to APNIC
To echo and earlier post, what's the operational importance of assigning adjacent /8s? Are you hoping to aggregate them into a /7? --Richard On Fri, Jan 22, 2010 at 10:16 AM, William Allen Simpson william.allen.simp...@gmail.com wrote: Nick Hilliard wrote: On 22/01/2010 13:54, William Allen Simpson wrote: Why not 36 37? Random selection to ensure that no RIR can accuse IANA of bias. See David's previous post: http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ Because relying on a blog post for policy really meets everybody's definition of rationality :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6.
Re: 1/8 and 27/8 allocated to APNIC
Would it make sense for the RIRs to just carve out the bad parts of the blocks, instead of IANA? Under current policy, would reserving bad bits make it more difficult for an RIR to get additional allocations? --Richard On Fri, Jan 22, 2010 at 11:56 AM, Leo Vegoda leo.veg...@icann.org wrote: On 22 Jan 2010, at 8:32, Brian Dickson wrote: [...] The granularity of allocations is arbitrary, and when scraping the bottom of the barrel, where there are known problems, it may time to get more granular. There's really no difference in managing a handful of /N's rather than /8's, if N is not that much bigger than 8. You need to change the global policy to do that. ICANN staff cannot allocate anything more specific than a /8 right now because the policy requires IPv4 allocations to the RIRs be in /8 units. http://www.icann.org/en/general/allocation-IPv4-rirs.html Regards, Leo
Re: New netblock Geolocate wrong (Google)
Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. yes! FWIW, there has been some work in the IETF on creating protocols to allow pretty rich location information to be published in reverse DNS. Basically, you publish a NAPTR pointer to a location server [1] where an interested client can ask for the location of a specific IP address [2][3]. (Publishing location in this way is a requirement in several systems for VoIP 9-1-1 around the world to allow first responders to ask networks for location. See for example the NENA i3 architecture in the US and a similar Canadian i2 for Canada.) The location representation these protocols use is a profile of the Geospatial Markup Language, so you can represent anything from a simple point to full GIS-like layers; you can also represent civic addresses (i.e., postal addresses) directly. If people are interested, let me know and I can provide pointers to some useful open-source software. --Richard [1] http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery [2] http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery [3] http://tools.ietf.org/html/draft-ietf-geopriv-held-identity-extensions [4] http://www.nena.org/standards/technical/voip/i3-requirements
Re: New netblock Geolocate wrong (Google)
Just to be fair here, I appreciate that there's some additional complexity here (not much -- I implemented a client for this yesterday in ~80 lines of Javascript), but LOC records don't cover everything. They're fine for stationary stuff, but not so great for anything that moves with any frequency (unless you're willing to make the DNS really dynamic). --Richard On Tue, Jan 19, 2010 at 7:23 AM, Randy Bush ra...@psg.com wrote: Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. yes! FWIW, there has been some work in the IETF on creating protocols to allow pretty rich location information to be published in reverse DNS. Basically, you publish a NAPTR pointer to a location server [1] where an interested client can ask for the location of a specific IP address [2][3]. (Publishing location in this way is a requirement in several systems for VoIP 9-1-1 around the world to allow first responders to ask networks for location. See for example the NENA i3 architecture in the US and a similar Canadian i2 for Canada.) The location representation these protocols use is a profile of the Geospatial Markup Language, so you can represent anything from a simple point to full GIS-like layers; you can also represent civic addresses (i.e., postal addresses) directly. surely, with its vast talents, the ietf can make this more complex. after all, look at the inflate-and-embellish stupidity that made the simple idea of bgp communities for data collecion, completely ueless, draft-meyer-collection-communities-00.txt /sarcasm i just wanna deal with a cidr block for stupid simple thing, not boil the ocean. and we have LOC RRs. no brilliance or inventiveness needed. randy
