IRS goes IPv6!
I Ar Es, At least they have received the 2610:30::/32 allocation from ARIN. Lets see if they how taxing they find IPv6 ;) Greets, Jeroen -- OrgName:Internal Revenue Service OrgID: IRS Address: Constitution Ave. NW City: Washington StateProv: DC PostalCode: 20224 Country:US NetRange: 2610:0030:::::: - 2610:0030:::::: CIDR: 2610:0030::::::/32 NetName:IRSNET6 NetHandle: NET6-2610-30-1 Parent: NET6-2610-1 NetType:Direct Allocation NameServer: NS1.TREAS.GOV NameServer: NS2.TREAS.GOV NameServer: NS21.TREAS.GOV NameServer: NS1.CIS.FED.GOV Comment: RegDate:2006-02-13 Updated:2006-02-13 signature.asc Description: This is a digitally signed message part
[NANOG] Cogent problem in NYC area
Title: [NANOG] Cogent problem in NYC area Cogent is having problems in the NYC area, they have said they are waiting for equipment to come back up. This has been going on for about 30 minutes now. They would not give me any more details than this. Regards, .myke
Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
http://www.cs.columbia.edu/~smb/papers/v6worms.pdf - courtesy Schneier on Security and then the ITU newslog. Internet Worms and IPv6 Bruce Schneier's Schneier on Security points to a paper dismissing the myth that worms won't be able to propagate under IPv6.
Re: NANOG36 wireless issue
On 2/13/06, Bill Fenner [EMAIL PROTECTED] wrote: http://disco-stu.dyndns.org/netdisco/public_map.html is a map of access points and their loads. The radius of the circle represents the number of associated users. I think you just re-invented http://www.plazes.com - though that's mostly for jetsetters like Joi Ito :) http://joi.ito.com/archives/2005/04/26/plazes_tracking_map.html -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On 2/14/06, Mohacsi Janos [EMAIL PROTECTED] wrote: In the 6NET project we identified, that exhaustive search in IPv6 is not feasible (e.g. nmap does not support it for IPv6), but there are also Interesting. By the way is there a currently missing between not and feasible there? Even given the sheer size of v6 space some of the other traits noted by SMB - like the tendency of network equipment to be clustered in the first few bits of a /48, and possibly observing new v6 netblocks get announced and routed might be used by someone to make intelligent guesses. And nmap can probably be hacked into doing that kind of scanning. After all when there's an unlimited number of hosts connected to the v6 network, all that needs to happen is a small botnet to develop, and then start to port scan. The potentially larger number of hosts that can get infected will probably help do an exhaustive search for you, so that v6 botnets start small and then grow exponentially in size over time. I rather suspect that the portscanning will grow to keep pace with the actual number of v6 connected hosts. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
In message [EMAIL PROTECTED], Sures h Ramasubramanian writes: http://www.cs.columbia.edu/~smb/papers/v6worms.pdf - courtesy Schneieron Secur ity and then the ITU newslog. Internet Worms and IPv6 Bruce Schneier's Schneier on Security points to a paper dismissing the myth that worms won't be able to propagate under IPv6. It's joint work with Angelos Keromytis and Bill Cheswick. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: NANOG36 wireless issue
On 2/14/06, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: I think you just re-invented http://www.plazes.com Well, Plazes requires user behavior to begin with, and doesn't distinguish between multiple access points with the same SSID and same subnet. Plazes could say NANOG in Dallas but not which side of the hotel. My system comes more from the network administrator's point of view, talking to the APs directly instead of hearing from the clients, plus can provide a more detailed version of where am I?. You're right that Plazes seems to be for people who want to brag about how much they roam around. I stopped using it when I found that the MacOS menubarlet crashes constantly when using tunnel interfaces. (Since fixed, I hear, but I don't think it's really my bag anyway.) Bill
Fed Bill Would Restrict Web Server Logs
Message: 3 Date: Thu, 09 Feb 2006 00:14:23 -0800 From: Declan McCullagh declan@well.com Subject: [Politech] Delete web server logs, or get fined by the Feds? Ed Markey's new bill [fs] To: politech@politechbot.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed I've posted the text here: http://www.politechbot.com/docs/markey.data.deletion.bill.020806.pdf A summary is here: http://news.com.com/2100-1028_3-6036951.html A bill just announced in Congress would require every Web site operator to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. An open question is whether Rep. Ed Markey's bill would require that Internet addresses be deleted by default from Apache and other web server logs. One reading is that it would be. But it's not clear whether an IP address falls under the definition of personal information. This bill applies to anyone running a web site, including individuals and bloggers. So it's not just companies that have to worry. Original posting from Declan McCullagh's PoliTech mailing list. Thought NANOGers would be interested since, if this bill passes, it would impact almost all of us. Just imagine the impact on security of not being able to login IP address and referring page of all web server connections! Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
Re: Fed Bill Would Restrict Web Server Logs
On 2/14/06, Jon R. Kibler [EMAIL PROTECTED] wrote: A bill just announced in Congress would require every Web site operator to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. Original posting from Declan McCullagh's PoliTech mailing list. Thought When no longer required for business purposes Your syslog's logrotate function does that for you already, for all reasonable purposes .. blows away logs that are say a week old. Email addresses etc - I guess that's cookie data etc. Or any other data that you gather but dont state a purpose for .. if you gather data saying you want to market to them, fine. If you gather data like that as part of a profile on a blog, fine. No hassles that I can see there. This kind of checks privacy violations / abuse that goes on when data is collected without your knowledge, or used for purposes you didnt intend it to be used for but didnt read fine print, or the people collecting your data dont care about reselling it to others. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
RE: ISP filter policies
Same question here. We have a filtering appliance that filters for porn, etc based on a subscription basis, but I've considered filtering phishing and spyware sites for all our customers. At what point does the ISP wanting to do good infringe upon the 'rights' of those who accidentally hurt themselves (many) and those who want to do everything (few). Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ricardo V. Oliveira Sent: Monday, February 13, 2006 10:35 PM To: nanog@merit.edu Subject: ISP filter policies Hi, i would like to know where i can get info about ISP filter policies, namely use of community values? Is there any page other than: http://www.nanog.org/filter.html (lots of broken links)? Thanks! --Ricardo
Re: Fed Bill Would Restrict Web Server Logs
On Tue, Feb 14, 2006 at 09:47:50AM -0500, Jon R. Kibler scribed: http://www.politechbot.com/docs/markey.data.deletion.bill.020806.pdf to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. Original posting from Declan McCullagh's PoliTech mailing list. Thought NANOGers would be interested since, if this bill passes, it would impact almost all of us. Just imagine the impact on security of not being able to login IP address and referring page of all web server connections! Call me weird, but I fail to see where the scary teeth lie in such a bill. First of all, it's phrased very abstractly and would hopefully have its language clarified by the time it escapes a committee. Second, the bill is fairly clear about the meaning of personal information, and it doesn't include things like IP addresses in its examples; the latter would be a matter for a court to decide, and it's not clear cut at all: ... that allows a living person to be identified individually, including ... : first and last name, home or physical address, ... Third, it says nothing at all about restricting what you can log: An owner of an Internet website shall destroy, within a reasonable period of time, any data containing personal information if the information is no longer necessary for the purpose for which it was collected or any other legitimate business purpose. If you need IP address logging to ensure the security of your website, then that sounds like a pretty legitimate business practice. The more interesting question is how _long_ you need to keep the personal information around for your for your legitimate business purposes. A week? A month? A year? Ultimately, it would probably boil down to a dash of best practices and a pinch of CYA. But there's nothing in there to freak out about for day to day operations. The worry is more that you'd probably have to ensure that your logs get blasted or sanitized according to a well-defined schedule. Which, when you think about it, might not be a bad thing at all. -Dave -- Dave Andersen [EMAIL PROTECTED] Assistant Professor 412.268.3064 Carnegie Mellon Universityhttp://www.cs.cmu.edu/~dga
Re: Fed Bill Would Restrict Web Server Logs
On Tue, Feb 14, 2006 at 10:33:19AM -0500, David G. Andersen wrote: On Tue, Feb 14, 2006 at 09:47:50AM -0500, Jon R. Kibler scribed: http://www.politechbot.com/docs/markey.data.deletion.bill.020806.pdf to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. Original posting from Declan McCullagh's PoliTech mailing list. Thought NANOGers would be interested since, if this bill passes, it would impact almost all of us. Just imagine the impact on security of not being able to login IP address and referring page of all web server connections! Call me weird, but I fail to see where the scary teeth lie in such a bill. First of all, it's phrased very abstractly and would hopefully have its language clarified by the time it escapes a committee. Second, the bill is fairly clear about the meaning of personal information, and it doesn't include things like IP addresses in its examples; the latter would be a matter for a court to decide, and it's not clear cut at all: Strange thing is that we have exact the opposite here in Europe. There is a new bill that has been passed that forces us to keep al logs (mail and web) for at least 1 or 2 years. Vriendelijke groeten, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: Fed Bill Would Restrict Web Server Logs
On 2/14/06, Frank Louwers [EMAIL PROTECTED] wrote: Strange thing is that we have exact the opposite here in Europe. There is a new bill that has been passed that forces us to keep al logs (mail and web) for at least 1 or 2 years. 6 months to 2 years I think. http://blogs.iht.com/tribtalk/technology/2006/02/09/subpoena_disclosures_to_protec/ --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
RE: Fed Bill Would Restrict Web Server Logs
Strange thing is that we have exact the opposite here in Europe. There is a new bill that has been passed that forces us to keep al logs (mail and web) for at least 1 or 2 years. Vriendelijke groeten, Frank Louwers That is far scarier.
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On Tue, 14 Feb 2006 18:42:33 +0530, Suresh Ramasubramanian said: After all when there's an unlimited number of hosts connected to the v6 network, all that needs to happen is a small botnet to develop, and then start to port scan. The potentially larger number of hosts that can get infected will probably help do an exhaustive search for you, so that v6 botnets start small and then grow exponentially in size over time. OK.. let's say we have a /48 allocated to an end site, and their router falls over at 1Mpps. The exhaustive search will completely clog their pipe for (2 ** (128 - 48))/100 seconds, or approximately 38,334,786,263 *years*. (That 2**80 is *huge*, a lot bigger than people think...) Even the most dim-witted site will notice after a day or two of this. And that's why a worm would have to use techniques like Steve and fiends wrote about. pgpFlyyGzZbSU.pgp Description: PGP signature
Re: Fed Bill Would Restrict Web Server Logs
Suresh Ramasubramanian wrote: On 2/14/06, Jon R. Kibler [EMAIL PROTECTED] wrote: A bill just announced in Congress would require every Web site operator to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. Original posting from Declan McCullagh's PoliTech mailing list. Thought When no longer required for business purposes Your syslog's logrotate function does that for you already, for all reasonable purposes .. blows away logs that are say a week old. Speaking with my e-commerce vendor hat on, server logs (apache, mail, application audit logs) and other information about visitors (especially those who have conducted a purchase transaction with us, or signed up to our newsletter) never stop having a business purpose - it's called referential integrity. We want to use them to track the behaviour fraudulent users for example. We also want to learn about how people use our site to make it easier. We want to ensure our mail systems are not approaching capacity. We want to know if our spam filtering is working, and how its use changes over time. etc.,etc.,etc. These are all business purposes. It's interesting that the US government is requiring less user data is stored when European politicians are calling for greater data and log retention rules.
RE: Fed Bill Would Restrict Web Server Logs
From: Andy Davidson Speaking with my e-commerce vendor hat on, server logs (apache, mail, application audit logs) and other information about visitors (especially those who have conducted a purchase transaction with us, or signed up to our newsletter) never stop having a business purpose - it's called referential integrity. We want to use them to track the behaviour fraudulent users for example. Anyone who runs mailing lists has to keep that info to be able to prove how and when someone opted in. David
Re: Fed Bill Would Restrict Web Server Logs
Mark Borchers wrote: Strange thing is that we have exact the opposite here in Europe. There is a new bill that has been passed that forces us to keep al logs (mail and web) for at least 1 or 2 years. Vriendelijke groeten, Frank Louwers That is far scarier. Which hard drive vendor wrote that law? They're the only people who will benefit from it. -- Jeff Shultz
Re: IRS goes IPv6!
On Tue, 14 Feb 2006, Jeroen Massar wrote: I Ar Es, At least they have received the 2610:30::/32 allocation from ARIN. Lets see if they how taxing they find IPv6 ;) so.. this is surprising why? the us-gov mandate for ipv6 uptake will mean lots of us-gov folks will be spinning up justifications that they are a 'service provider' and need a /32... cause they won't accept PA space (or I don't think they will accept PA space as a long term solution) ... or I might be smoking crack :) who knows.
Re: Fed Bill Would Restrict Web Server Logs
On Tue, 14 Feb 2006 16:14:11 GMT, Andy Davidson said: It's interesting that the US government is requiring less user data is stored when European politicians are calling for greater data and log retention rules. Obviously, none of the Total Info Awareness proponents were able to get their tentacles involved here... pgp0EPyQw2MJj.pgp Description: PGP signature
RE: Fed Bill Would Restrict Web Server Logs
On Tue, 14 Feb 2006, David Hubbard wrote: From: Andy Davidson Speaking with my e-commerce vendor hat on, server logs (apache, mail, application audit logs) and other information about visitors (especially those who have conducted a purchase transaction with us, or signed up to our newsletter) never stop having a business purpose - it's called referential integrity. We want to use them to track the behaviour fraudulent users for example. Anyone who runs mailing lists has to keep that info to be able to prove how and when someone opted in. Have you ever tried getting opt-in information out of someone, especially when they know they've screwed up? You practically need a subpeona to do it. In many cases (I went through this recently with ZDnet) you literally have to play the escalation game just to rattle enough cages to get people to realize you're a: serious and b: not a kook. Oddly enough, I have the hardest time with the latter. ;) It'll be interesting to see what this legislation looks like when/if it gets signed. Maybe it'll finally be the extra kick I need to get some of our larger databases purged. - billn
Re: Fed Bill Would Restrict Web Server Logs
I guess the question is how to read legitimate word. ^.^ I guess the bill was written in mind of privacy concern. But also there is some requirement for security/law-enforcement viewpoint. I received the request from some law-enforcement about actual user of IP address 3 year ago or older. Without all log info, how can I tell it? It seems this bill will bring more ISP/ASP to the court to clarify what is legitimate or not. From privacy viewpoint, I guess people wants to remove all their trace from the Internet. But from security and practical concerns from ISP/ASP, they want to have all traces from the people. I think the government needs to enforce ISP/ASP to keep all trace for certain level, but with more stricted access method. I'm really curious whether this was a kind of post-action to the cell-phone use log business such as locatecell.com or something like that. Hyun Jon R. Kibler wrote: Message: 3 Date: Thu, 09 Feb 2006 00:14:23 -0800 From: Declan McCullagh declan@well.com Subject: [Politech] Delete web server logs, or get fined by the Feds? Ed Markey's new bill [fs] To: politech@politechbot.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed I've posted the text here: http://www.politechbot.com/docs/markey.data.deletion.bill.020806.pdf A summary is here: http://news.com.com/2100-1028_3-6036951.html A bill just announced in Congress would require every Web site operator to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. An open question is whether Rep. Ed Markey's bill would require that Internet addresses be deleted by default from Apache and other web server logs. One reading is that it would be. But it's not clear whether an IP address falls under the definition of personal information. This bill applies to anyone running a web site, including individuals and bloggers. So it's not just companies that have to worry. Original posting from Declan McCullagh's PoliTech mailing list. Thought NANOGers would be interested since, if this bill passes, it would impact almost all of us. Just imagine the impact on security of not being able to login IP address and referring page of all web server connections! Jon Kibler
Re: Fed Bill Would Restrict Web Server Logs
Date: Tue, 14 Feb 2006 09:47:50 -0500 From: Jon R. Kibler [EMAIL PROTECTED] Date: Thu, 09 Feb 2006 00:14:23 -0800 From: Declan McCullagh declan@well.com I've posted the text here: http://www.politechbot.com/docs/markey.data.deletion.bill.020806.pdf A summary is here: http://news.com.com/2100-1028_3-6036951.html A bill just announced in Congress would require every Web site operator to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. An open question is whether Rep. Ed Markey's bill would require that Internet addresses be deleted by default from Apache and other web server logs. One reading is that it would be. But it's not clear whether an IP address falls under the definition of personal information. This bill applies to anyone running a web site, including individuals and bloggers. So it's not just companies that have to worry. Original posting from Declan McCullagh's PoliTech mailing list. Thought NANOGers would be interested since, if this bill passes, it would impact almost all of us. Just imagine the impact on security of not being able to login IP address and referring page of all web server connections! Jon: The proposed bill states to delete when data is no longer required for legitimate business purposes. If you business model requires that you keep the logs for some tracking function, then keep them. As long as the logs are required for business purposes. Once the business purpose finishes, then delete them. How is this different that the way we operate now? Except that, if the bill passes, then - possible/probably - our privacy policy (such as they are) will have to state the business purposes... IANAL, but my $0.002 worth. Regards, Gregory Hicks --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: Fed Bill Would Restrict Web Server Logs
This is a pro-privacy bill that would regulate business, and it's been introduced by a Democrat in a Republican-controlled Congress with a Republican president, at a time when privacy is out of favor. It's not going to pass. (To me, of course, that's a bug, especially since I'd rather that stronger privacy legislation were passed. But I'm not holding my breath.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: IRS goes IPv6!
---Original Message--- From: Christopher L. Morrow [EMAIL PROTECTED] Subject: Re: IRS goes IPv6! Sent: 14 Feb '06 08:31 On Tue, 14 Feb 2006, Jeroen Massar wrote: I Ar Es, At least they have received the 2610:30::/32 allocation from ARIN. Lets see if they how taxing they find IPv6 ;) so.. this is surprising why? the us-gov mandate for ipv6 uptake will mean lots of us-gov folks will be spinning up justifications that they are a 'service provider' and need a /32... cause they won't accept PA space (or I don't think they will accept PA space as a long term solution) ... So isn't this yet another reason why we need a rational PI policy, so organizations don't have make up reasons why they are LIRs.
Re: Fed Bill Would Restrict Web Server Logs
On Tue, 14 Feb 2006, Hyunseog Ryu wrote: I guess the question is how to read legitimate word. ^.^ I guess the bill was written in mind of privacy concern. But also there is some requirement for security/law-enforcement viewpoint. I received the request from some law-enforcement about actual user of IP address 3 year ago or older. Without all log info, how can I tell it? In the context of the legislation in question, if the user is still a current customer, you have a legitimate business use for the data. If the user was no longer a customer, I would surmise that you should have purged it, as you would no longer have a need for that user's personal data. I'm really curious whether this was a kind of post-action to the cell-phone use log business such as locatecell.com or something like that. An exploration of the side effects would be interesting. I think it'll provide a legal cudgel for mailing lists and opt-in tracking, as well as ensuring that your information is purged when/if you opt-out. It may also have dampening effects on the sale/trade of personal information, as it would now be questionably criminal to possess the personally identifying information of a person you have engaged in zero business with. From the text of the bill, there are some pretty loose points that'll give lawyers a lot of vine to swing from, including the definition of 'legitimate business practice'. Associating all of it to 'Internet website', as defined, is another loophole waiting to happen. I think the single best element of the bill is the declaration that consumers have an ownership in interest in their personal information. Owndership implies control, and by extension, some amount of control in who gets to have it. I'd like to see what happens when the final bill is mated with US Federal CAN-SPAM law. - billn
Re: IRS goes IPv6!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeroen Massar wrote: I Ar Es, At least they have received the 2610:30::/32 allocation from ARIN. Lets see if they how taxing they find IPv6 ;) And who'd have thought they would be such late filers :-) [IPv6 whois information for NET6-2001-49C8-1 ] [whois.arin.net] OrgName:US Department of the Interior OrgID: UDI-5 Address:625 Herndon Parkway Address:MS 012 City: Herndon StateProv: VA PostalCode: 20170-5416 Country:US NetRange: 2001:49C8:::::: - 2001:49C8:::::: CIDR: 2001:49C8::::::/32 NetName:USDOI NetHandle: NET6-2001-49C8-1 Parent: NET6-2001-4800-0 NetType:Direct Allocation Comment: RegDate:2005-11-10 Updated:2005-11-10 Greets, Jeroen -- OrgName:Internal Revenue Service OrgID: IRS Address: Constitution Ave. NW City: Washington StateProv: DC PostalCode: 20224 Country:US NetRange: 2610:0030:::::: - 2610:0030:::::: CIDR: 2610:0030::::::/32 NetName:IRSNET6 NetHandle: NET6-2610-30-1 Parent: NET6-2610-1 NetType:Direct Allocation NameServer: NS1.TREAS.GOV NameServer: NS2.TREAS.GOV NameServer: NS21.TREAS.GOV NameServer: NS1.CIS.FED.GOV Comment: RegDate:2006-02-13 Updated:2006-02-13 - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8ipJE1XcgMgrtyYRApkdAJ9oRi468Hv+I9xbiqx2OdA50a5eWACg8tRS 7KOT+k6IS8v4ArRo0Avs0NU= =QGN4 -END PGP SIGNATURE-
Re: Fed Bill Would Restrict Web Server Logs
On Tue, Feb 14, 2006 at 11:31:48AM -0500, [EMAIL PROTECTED] wrote: On Tue, 14 Feb 2006 16:14:11 GMT, Andy Davidson said: It's interesting that the US government is requiring less user data is stored when European politicians are calling for greater data and log retention rules. Obviously, none of the Total Info Awareness proponents were able to get their tentacles involved here... Hum... tentacles... http://www.cthulhu.org/cthulhu/index.html --bill unsigned email is a sign of plausable deniability...
Re: Fed Bill Would Restrict Web Server Logs
* Frank Louwers: Strange thing is that we have exact the opposite here in Europe. There is a new bill that has been passed that forces us to keep al logs (mail and web) for at least 1 or 2 years. It's not a bill, it's a EU directive which still has to be implemented in national law. Nothing in the directive requires that operators of non-interactive web sites (the vast majority) retain any data. Only if you identify your users, you might be required to keep some logs. Implementation in national law might change that, especially since the directive is remarkably unclear about the selection criteria used for mapping communication events to individuals.
NANOG36-NOTES 2006.02.14 talk 1 IRR power tools
Apologies in advance, notes from this morning will be a bit more scattered, as I was working on an issue in parallel to taking notes. Matt 2006.02.14 talk 1 IRR Power Tools 12:10 to 12:25, extra talk added, not on printed agenda. Thanks to those who submitted lightning talks. PC committee members are doing moderation, Todd Underwood will be handling the first session this morning. There will be 3 talks about tools for operators 1 IRR and 2 Netflow tools. Be thinking of interesting questions to ask. Todd has to introduce RAS at 9am, 7am west coast time which is normally his bedtime. IRR power tools, Dec 2004 first generation re-write. IRR--a quick review People have been asking him why do we need the IRR? Any time you have a protocol like BGP that can propagate information, you need some form of filtering in place to limit damage. IRRs are databases for storing lists of customer information. Written to speak RPSL some speak RPSLng. RADB ALTDB VERIO, LEVEL3, SAVVIS RIR-run databases: ARIN, RIPE, APNIC, etc. IRRs better than manual filtering. huge list on the slides. Filtering is needed, and hard to keep updated by hand. Why doesn't everyone use IRR? Many people do In Europe, pretty much total support in Europe; it's required by RIPE, providers won't deal with you if you don't keep your entries up, large exchanges likewise check. Few major networks in US use IRR too: NTT/Verio Level3 Savvis Most people don't. Why doesn't everyone use it? In US, it's too complex for customers. support costs go up if you have to teach customers. Networks don't like to list their customers in a public database that can be mined by competitors RAS figured he could fix at least one piece Wrote a tool to help with: automatic retrieval of prefixes behind an IRR object automatic filtering of bogon or other undesirable routes Automatic aggregation of prefixes to reduce config size Tracking and long-term recording of prefix changes Emails the customer and ISP with prefix changes Exports the change data to plain-text format for easy interaction with non-IRR enabled networks Generates router configs for easy deployments. Doesn't do import/export policies, doesn't do filter-sets, rtr-set, peering-set, etc. Just focuses on essential portions. Tool was written around IRRToolSet initially, but the C++ code didn't compile nicely. This isn't a complete replacement for IRRToolSet, but provides the basic functionality A few conf files: IRRDB.CONF EXCLUSIONS.CONF NAG.CONF ./irrpt_fetch grabs the current database info It also speaks clear english on add/remove of prefixes for access lists; default format is english, but you can change it to diff format. ./irrpt_pfxgen ASNUM generates a prefix list suitable for the customer interface. Can use -f juniper to create juniper filters. http://irrpt.sourceforge.net/ Always looking for more feedback; it's been deployed by a few people in the peering community; this will be its first widescale announcement. Future plans: Add support for IPv6/RPSLng needs IPv6 aggregation tools RADB tool uses a faster protocol, RIPE just breaks down one level; you have to do multiple iterations to get the full expansion. Servers tend to time out before you can get all the answer; RIPE servers have hard 3 minute timeout that closes the socket. Add SQL database support for a backend Convert from a script to a real application IRRWeb -- http://www.irrweb.com/ He'll talk about irrweb at next nanog. Allow end users to register routes without needing to know ANYTHING about RPSL You can play with it, register routes, but it doesn't publish anywhere. That's it--happy valentine's day! Richard A Steenbergen ras at nlayer.net Susan notes that RADB is developed by Merit, the two primary developers are here today Chris Fraiser, main cust interface now Larry Blunk is RPSLng person, also here today. Right now, no mirroring between IRRs, you have to mesh with everyone else when a new IRR comes up. RADB at least does pick up from the others, so right now RADB is the best spot to do your queries against. Todd asks about filters; does it do prefix list only, or prefix list plus as-path? It builds off as's behind other as's, which might not be the best model; latest code is starting to understand as-sets. To do it properly, you might need import/export policy support. Randy Bush, IIJ. Like IPv6, this meeting marks the tenth anniversary of Randy pushing for IRR adoption. And like IPv6, adoption rate has not been going well. What's wrong? Pretty much too complex, which is why this effort is to make it much simpler, to try to get more uptake in the US. Todd notes that 2 things; 1, tools are too difficult; this addresses that. second piece is that in US, allocations aren't tied to registry entry creation; this won't solve that part at all. For the second part, the benefits are seen mostly the closer you are to the registration process. Anyone can register any block; and if you don't use AS123:, people can
NANOG36-NOTES 2006.02.14 talk 2 Netflow Visualization Tools
2006.02.14 talk 2 Netflow tools Bill Yurcik byurcik at ncsa.uiuc.edu NVisionIP and VisFlowConnect-IP probably a dozen tools out there, this is just two of them. Concenses is there's something to this. They're an edge network, comes into ISP domain, their tools are used by entities with many subnet blocks. Overview Project Motifivation Netflows for Security Two visualization tools NVisionIP VisFlowConnect-IP Summary Internet Security: N-Dimensional Work Space large--already lots of data to process complex--combinatorics explode quickly time dynamics--things can change quickly! Visualizations can help! in near-realtime overview-browse-details on demand People are wired to do near-realtime processing of visual information, so that's a good way to present information for humans. HCI says use overview-browse-details paradigm. Netflows for security can identify connection-oriented stats to see things like attacks, DoS, DDoS, etc. Most people don't use the data portion of the flow field, the first 64 bytes, they just look at header info or aggregated flow records. Can spot how many users are on your system at a given time, to schedule upgrades. Who are your top talkers? How long do my users surf? What are people using the network for? Where do users go? Where did they come from? Are users following the security policy? What are the top N destination ports? Is there traffic to vulnerable hosts? Can you identify and block scanners/bad guys? This doesn't replace other systems like syslog, etc.; it integrates and works alongside them. architecture slide for NCSA. Can't really do sampled view for security, so probably need distributed flow collector farm to get all the raw data safely. Two visualization tools: NVisionIP, VisFlowConnect-IP focus on quick overview of tools security.ncsa.uiuc.edu/ 3 level hierarchical tool; galaxy view (small multiple view) ((machine view)) Galaxy is overview of the whole network. color and shape of dots is each host in a network. settable parameters for each dot. Animated toolbar and clock show changes over time in the galaxy. Lets you get high-level content quickly and easily. Domain view lets you drill in a bit more; small multiple view looks at the traffic within the block. upper histogram is lower, well known ports; lower histogram is ports over 1024 You can click on a given multiple view entry to delve into one machine. Many graphs for each machine in the most detailed view. well known ports first, then rest of ports (sorted) then source and destination traffic broken out. Designed for class Bs. http://security.ncsa.uiuc.edu/distribution/VisFlowConnectDownload.html 3 vertical lines, comes from edge network perspective; middle line is edge network to manage. You set range of networks you care about. Outside lines are people sourcing or sinking traffic to you, from outside domains. There's a time axis, traffic only shown for the slice of time currently under consideration. Uses VCR-like controls to move time forward/backward Lets you see traffic/interactivity, drill into that domain, see host level connectivity flows. Shows MS Blaster virus traffic as an example. Example 2, a scan example. Just because it looks like one IP hitting many others doesn't mean it's really a security incident, though; could be a cluster getting traffic. web crawlers hitting NCSA web servers make for a very charateristic pattern over time. Summary Netflows analysis is non-trivial, NVisionIP VisFlowConnect-IP lots of references listed in very fine blue font. http://security.ncsa.uiuc.edu/distribution/NVisionIPDownload Avi Freedman, Akamai, Argus was mentioned a lot; it lets you grab symmetric netflows, but also does TCP analysis, shows some performance data as well. not sure if people are studying the impact of correlating argus data with flow data. Roland Douta? of Cisco; many people are using netflow to track security issues. They now have ingress and egress flow data on many of their platforms. In reading paper describing it, there's data conversion that needs to happen into an internal format that nVision can understand. It reads log files at the moment, takes about 5 minutes to process files. Lets them take different file data sources, make the tool for visualization independent of the input format. They can read large files, but there is a performance hit when doing it. Are they planning on doing further work on the tool to collect TCP flags, for frags, drop traffic, etc? They've looked at it, but they leave it to IDS tools for flag activity. Might be of interest to consider for future versions of the tools. Last question came up, echoed about argus. Question about interactivity, they are working on feedback through tools. Question about alarming on patterns; but once you start alarming or putting up visual indicators, it distracts from rest of the overall pattern, you tend to miss other information.
NANOG36-NOTES 2006.02.14 talk 3 Flamingo Netflow Visualization Tool
2006.02.14 talk 3 Flamingo netflow visualization Manish (from BGP Inspect project from Merit) bgpinspect.merit.edu:8080 He'll be talking later at the Tools BOF as well apparently. Introduction: What is Flamingo? Visualization The Flamingo Tool combining visualizations with controls Case Studies traffic anomaly network scans worm traffic P2P traffic the slashdot effect. The tool has been under development for a year; John, in audience, and Mike (now employed) have been working on it as undergrads. It's just a view into netflow, no filters or adjustment of data it's just a visualization system. client/server architecture a single server can support multiple clients Visualation methods 5 different views extended quad tree implementation volume by src/dst IP prefix volume by src/dst AS Basic quad tree represent 32bit IP address into fixed space. 4 areas representable by 2 bits. Keep splitting 16 times, you represent 32 bit address in 2D mapping. convert it into 3 dimension, have an axis of freedom to represent additional info. So one side is the quad tree, the Z axis is volume of traffic, so you can see relative volumes. nice slide showing visualization of the traffic flow patterns. Can show traffic flows aggregated by src/dst IP; now there's 2 surfaces needed on the cube, so they use line thickness between the surfaces to show flow sizes between ASes. last visualization incorporates port info as well But since there's only one axis left; so now port level info is on z axis. so IP/port is X1Y1Z1; same for dest IP and port. Once there are coordinates, the line can be drawn, scale the width based on the volume, and now you have the full info in one view. Same colour used to represent traffic from the same source ntuple. combine 2D and 3D representation of data to help keep yourself oriented. They have text representatiosn of information, same as visual data, but in text form. Slider bars allow thresholding of what gets displayed, to prevent clutter; only over a certain size, or only certain ports, etc. Can also apply labels to help pull information out for fast refrence. You can also restrict the address space you care about to only look at certain subnets. Case study: Traffic anomaly sunday Oct 16, 2005 large burst of traffic from one host at umich, lasted 6 hours, four targets, not widely distributed, it was UDP traffic. Was visible in normal view. from 12pm to 6pm. visible on main view, zoomed in, and the 4 million flows show as a huge block. going to src/dest view lets you see where the traffic is going. adding the port info, and you see the entire port space is being sprayed. Another case study--worm traffic doing port 42 scans a fan view on the graph, highly visible. An artificial case study, a host scanning a /24 subnet SSH scans also show up as many many ports probing a single port; a reverse fan. Slashdot effect on campus Oct 31 2004; have before and during pictures showing the huge traffic swing. Zotob worm infection; random destination IPs, but same port, coming from same host, cone effect. P2P traffic; single host with multiple connections to different destinations, significant volume to each. Darkspace traffic visualizations show nothing but scans, show up really dramatically. Conclusion The Flamingo Visualization Tool provides users with the ability to easily explore and extract meaning information regarding traffic flows in their network. More will be discussed at the Tools BOF this afternoon. http://flamingo.merit.edu/ Break now, come back at 10:50. Someone left a jacket at the Yahoo party with a digital camera; describe it to the registration desk to get it back.
NANOG36-NOTES 2006.02.14 talk 4 Flooding via routing loops
2006.02.14 talk 4 Flooding attacks Jianhong Xia A new talk added right before lunch by Randy Bush will push us to 12:25. Two talks coming up about DoS attacks against control information Flooding Attacks by exploiting persistent forwarding loops. Introduction: routing determines forwarding path. Transient forwarding loops happen all the time during convergence; that's normal. But this focuses on persistent fowarding loops. why would persistent loops exist? Example on neglecting pull-up routes. Router announces 18.0/16 to internet router A has default pointing to B router A uses 18.0.0/24 only Any traffic to 18.0.1.0-18.0.255.255 will enter the forwarding loop between A and B Risk of persistent forwarding loops can amplify based on ttl of packets injected into the looping pair of routers. Can create a denial of service by flooding the upstream links between routers in front of host they want to knock off. any other hosts behind that link are imperiled addresses Measurement Design: balancing granularity and overhead samples 2 addresses in each /24 IP block Addresses space collection addresses covered by RouteView table de-aggregate prefixes into /24 prefixes fine-grained prefixes data traces traceroute to 5.5 million fine-grained prefixes measurement lasts for 3 weeks in sept 2005 Almost 2.5% of routable addresses have persistent forwarding loops Almost .8% of routable addresses are imperiled addresses. Validating these persistent forwarding loops from multiple places from asia, europe, west and east cost of US 90% of shadowed prefixes consistently have persistent forwading loops Validation to multiple addresses in shadowed prefixes sampling 50 addresses in each shadowed prefix 68% of shadowed prefixes shows that... Properties of the loops How long are the loops? 86.6% of loops are 2 hops long 0.4% are more than 10 hops long some are more than 15 hops location 82.2% of persistent loops happen within destination domain implications significantly amplify attacking traffic can be exploited from different places. (oops. Matt gets paged out to deal with issue, so no more notes for a while).
protocols that don't meet the need...
A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. This will mean that people who regularly attend both will have overlap issues, but if one meeting every year or two is joint there is an opportunity for those who can't justify the extra trips to at least have some feedback to try and close the loop on protocol design. Tony
NANOG36-NOTES 2006.02.14 talk 7 Randy IRR routing security revisited
Many apologies...I'm no Stan Barber, but still doing my best to keep up with the note-taking. ^_^;; Matt Slides are on Randy's site at http://rip.psg.com/~randy/060214.nanog-pki.pdf What I want for Eid ul-Fitr Randy Bush randy at psg.com Definition of Eid ul-Fitr; end of Ramadan; breaking of the fasting period, and of all evil habits. Roughly October 24th this year. 10 years ago Randy plead for people to use IRR; he gives, it didn't work, it has bad data, it doesn't work. Let's get rid of it. Routing security is what we need. Routing security gap assume router has been captured. routing security (not router) is a major problem. http://rip.psg.com/~randy/060119.janog-routesec.pdf need PKI, storing and passing and signing certificates. Public Key Infrastructure PKI Database RIR Certs ISP Certs End Site Certs IP Addresss Attestations ASN Attestations IP and AS Attestations specifies identity == pyblic ckey of recipient signed by allocator's private key Follows allocation hierarchy IANA (or whomever) to RIR RIR to ISP ISP to downstream ISP or end user enterprise IP allocation example IANA to RIR S.iana (192/8, rir) RIR allocatees to ISP S.rir(192.168/16) and so on down the chain. Each chain uses the private key to sign the certs to hand down the chain. ISP/End-site-certs May be acquired anywhere. Don't have to be chained to a single master organization, and can use the same one for multiple RIRs, orgs, etc. RIRs can issue as a service for members who don't get them anywhere. They need no attestation because they are only used in business transactions where they are exchanged and managed by contract, or Bound to IP or ASN attestations by the RIRs or upstream ISPs. Big ISPs may use an ARIN identity for an APNIC allocation or business transaction. Since the keys are acquired separately, doesn't matter where the certs come from, or where used. RIR Identity similar. it's their public key can get it from 'above', RIR NRO, IANA, or they can even self cert. No provision for revocation, however. PKI Interfaces/Users Nice slide showing the interrrelationships; go see the slides for it, I won't try to render it in ASCII in realtime. The certificates are directly exchanged as part of the business transaction when goods (IPs, ASNs, etc) are exchanged. Goal is to have formally verifiable route attestations, so want replicas of data near routers to be used to determine validity of route origination and propagation. Transacting with PKI RFC2585 descripts FTP and HTTP transport for PKI no need for transport security! Tools for RIRs Generate and receive ISP certs Receive ASN and IP space attestations from upstairs Tools for ISPs generate/get certs register role certs generate certs for downstreams sign allocations to downstreams Open Issues Coordination of updates one central repository not feasible LDAPv3 RFC3377 and RFC2829 for authentication Cert/key rollover and revocatoin not covered May require a separate and secured communication channel NSF via awared ANI-0221435 Steve Bellovin JI >From microphone, are there TTLs on certs? Yes, which is why ISP certs are separated out. Addresses from ARIN are only yours as long as you keep paying ARIN. Tie certs to contract terms. But the ISP identity cert is yours, nobody else should have control over rollover and expiration. APNIC is working to have web pges Andrew Dole, Boeing; how to get funded--Randy will take cash donations. Andrew thinks it'll take 10 million to get the ball rolling. Randy doesn't think that's the problem. The operator community would prefer to see a rigorously correct and verifiable solution with reasonable security infrastructure rather than one more hack on the IRR. Second question. What is forum to discuss and nail down the details? He'll be at APNIC in 2 weeks; for this region the ARIN meeting in Montreal, and this meeting is good too. Nobody seems to be sure where the right place to do this is. But Randy thinks the important part is to SEND the message, that there is a valid path. Vince Fuller. Soliciting input from this group is a good thing, but be more targetted. Figure out why the previous efforts failed, and target them. Chris Morrow, Ted Seely...Randy targets some specific people in the audience. Chris Morrow notes that one challenge he faces is being able to verify if filters are correct. Randy notes the ROUTER will verify the validity itself. Chris feels doing it in OSS system is safer. RS--how do you deal with crufty stuff? RIRs and community will have to deal with that, he's just talking about giving tools to make it possible. Sandy Murphy, Sparta--Randy, you've said there's no prefix lists needed for this; but this could be used for building filter lists, or checking updates, or for tracking customers who call in with issues, etc. this is a first step for a whole BUNCH of things. So no matter what else we want to build on top of it, this really is the first level of the foundation that needs to be built.
RE: protocols that don't meet the need...
I am not going to speak for the IETF, but why would they? Their meetings are already open, and to be globally fair the proposed coordinators would have to attend 3-5 extra meetings a year to cover all the ops groups. Tony -Original Message- From: Eastgard, Tom [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:01 PM To: Tony Hain; nanog@merit.edu Subject: RE: protocols that don't meet the need... -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 12:35 PM To: nanog@merit.edu Subject: protocols that don't meet the need... A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. This will mean that people who regularly attend both will have overlap issues, but if one meeting every year or two is joint there is an opportunity for those who can't justify the extra trips to at least have some feedback to try and close the loop on protocol design. Would it make sense to ask IETF to provide a focal or coordinate(s?) to NANOG who would host a BOF(s?) on IETF issues --- not to debate, explain or work them but to board the issues and concerns of the operating community? Point being to provide a lightly structured and cost effective mechanism for operators to give feedback without having to attend three more meetings per year? T. Eastgard
Re: protocols that don't meet the need...
On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said: Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. The IETF apparently has some major scheduling problems as it is, because there are very few venues that can handle the number of people that show up *and* have the right mix of large rooms and many smaller break-out rooms. Trying to get it into a hotel opposite a NANOG would just exacerbate the problem. And there's nothing stopping NANOG types from joining an IETF working group and participating via e-mail - there's a large number of people who have contributed to the IETF process and never actually been sighted at an IETF meeting. pgpTQ5gIH8ANS.pgp Description: PGP signature
RE: protocols that don't meet the need...
I agree that attendance is not required, but it can help some discussions. Given the logistical differences it would be much easier to schedule NANOG into a nearby hotel than to try to move the IETF around. For example this time if NANOG had been a month later it would have been in the same city yet different hotels. I understand that synchronized meetings it not trivial, but it is worth considering. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:10 PM To: Tony Hain Cc: nanog@merit.edu Subject: Re: protocols that don't meet the need... On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said: Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. The IETF apparently has some major scheduling problems as it is, because there are very few venues that can handle the number of people that show up *and* have the right mix of large rooms and many smaller break-out rooms. Trying to get it into a hotel opposite a NANOG would just exacerbate the problem. And there's nothing stopping NANOG types from joining an IETF working group and participating via e-mail - there's a large number of people who have contributed to the IETF process and never actually been sighted at an IETF meeting.
Re: protocols that don't meet the need...
So, NANOG has worked in the past (eg: ARIN) at joint meetings at a venue before, perhaps something similar would work. I find it interesting that NANOG and IETF are both in Dallas about a month from each other and both parties likely navigated the logistics issues of connectivity, etc.. for these hotels for a slightly overlapping audience. Do people think something like the NANOG-ARIN would work for NANOG-IETF? That might allow cross-breeding/ROI/whatnot and value to both communities. - jared On Tue, Feb 14, 2006 at 01:17:46PM -0800, Tony Hain wrote: I agree that attendance is not required, but it can help some discussions. Given the logistical differences it would be much easier to schedule NANOG into a nearby hotel than to try to move the IETF around. For example this time if NANOG had been a month later it would have been in the same city yet different hotels. I understand that synchronized meetings it not trivial, but it is worth considering. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:10 PM To: Tony Hain Cc: nanog@merit.edu Subject: Re: protocols that don't meet the need... On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said: Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. The IETF apparently has some major scheduling problems as it is, because there are very few venues that can handle the number of people that show up *and* have the right mix of large rooms and many smaller break-out rooms. Trying to get it into a hotel opposite a NANOG would just exacerbate the problem. And there's nothing stopping NANOG types from joining an IETF working group and participating via e-mail - there's a large number of people who have contributed to the IETF process and never actually been sighted at an IETF meeting. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: protocols that don't meet the need...
Tony/all, I am not going to speak for the IETF, but why would they? Their meetings are already open, and to be globally fair the proposed coordinators would have to attend 3-5 extra meetings a year to cover all the ops groups. I am also not speaking for the IETF (IAB), but the IAB has undertaken the task of trying to bring a little of what's happening in the IETF to the operator community (and hopefully in the process engaging folks to come to the IETF). Now, while many in the IETF argue that there is no such thing as an operator community, I personally see it differently, and there are many of us who think that operator input is sorely missing from the IETF process. That is one of the reasons we did the NANOG 35 IPv6 multihoming BOF (and are doing the same at the upcoming apricot meeting). So (and again, not speaking for the IAB), my perspective is that we really need your insight and perspectives, more generally, your help in solving some of the difficult problems before us (a viable routing and addressing architecture for IPv6 comes to mind). All of that being said, I would be glad to facilitate with the IETF in any way I can. Perhaps someone from the NANOG PC/SC or Merit can contact me offline and we can look at with our options are. Any takers? Dave Tony -Original Message- From: Eastgard, Tom [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:01 PM To: Tony Hain; nanog@merit.edu Subject: RE: protocols that don't meet the need... -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 12:35 PM To: nanog@merit.edu Subject: protocols that don't meet the need... A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. This will mean that people who regularly attend both will have overlap issues, but if one meeting every year or two is joint there is an opportunity for those who can't justify the extra trips to at least have some feedback to try and close the loop on protocol design. Would it make sense to ask IETF to provide a focal or coordinate(s?) to NANOG who would host a BOF(s?) on IETF issues --- not to debate, explain or work them but to board the issues and concerns of the operating community? Point being to provide a lightly structured and cost effective mechanism for operators to give feedback without having to attend three more meetings per year? T. Eastgard pgpE2MbQ5fMiQ.pgp Description: PGP signature
Re: protocols that don't meet the need...
---Original Message--- From: [EMAIL PROTECTED] Subject: Re: protocols that don't meet the need... Sent: 14 Feb '06 13:10 On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said: Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. Not a substitute for attendance and face-to-face meetings, but ISOC has started publishing the IETF journal. It is a pretty long read, but I've found it useful to catchup on working groups. http://ietfjournal.isoc.org/
Re: protocols that don't meet the need...
On Feb 14, 2006, at 4:47 PM, David Meyer wrote: Tony/all, I am not going to speak for the IETF, but why would they? Their meetings are already open, and to be globally fair the proposed coordinators would have to attend 3-5 extra meetings a year to cover all the ops groups. I am also not speaking for the IETF (IAB), but the IAB has undertaken the task of trying to bring a little of what's happening in the IETF to the operator community (and hopefully in the process engaging folks to come to the IETF). Now, while many in the IETF argue that there is no such thing as an operator community, I personally see it differently, and there are many of us who think that operator input is sorely missing from the IETF process. That is one of the reasons we did the NANOG 35 IPv6 multihoming BOF (and are doing the same at the upcoming apricot meeting). Hmm, well, when there is lots of vendor and academia involvement, no, there's no operator community presented in number of things I'm following in the IETF. Take manet, for example, I don't even know to begin where to inject operator concerns/requirements. :-/ I think this is as much an IETF issue as it is of the operator community. Operators need to devote time to IETF to make the work in the IETF most relevant to the operators needs. Best regards, Christian
Re: protocols that don't meet the need...
Of course, there is nothing stopping NANOG or anyone else from collocating their meetings to be near the IETF's (in time or space)... but right now they would have a tough time figuring where that would be :) The IETF commits to having its meetings not collide with certain other meetings, and dates are typically set some years in advance : http://www.ietf.org/meetings/0mtg-sites.txt Because of the recent reorganization, the IETF meetings are only specified through 2007, but this will shortly be extended for another few years. Once set, these date cannot be changed except for force majure. Recently IETF meetings have not been announced too long in advance (this summer's location is still officially TBD on this list, for example). I know that the IAD is scrambling to fill in the where part of this list into the future. Hopefully, in the near future the IAOC and the IAD will have meeting sites planned out 2 years or so in advance. Maybe, then, a collocation could be discussed. Regards Marshall Eubanks On Feb 14, 2006, at 4:37 PM, Jared Mauch wrote: So, NANOG has worked in the past (eg: ARIN) at joint meetings at a venue before, perhaps something similar would work. I find it interesting that NANOG and IETF are both in Dallas about a month from each other and both parties likely navigated the logistics issues of connectivity, etc.. for these hotels for a slightly overlapping audience. Do people think something like the NANOG-ARIN would work for NANOG-IETF? That might allow cross-breeding/ROI/whatnot and value to both communities. - jared On Tue, Feb 14, 2006 at 01:17:46PM -0800, Tony Hain wrote: I agree that attendance is not required, but it can help some discussions. Given the logistical differences it would be much easier to schedule NANOG into a nearby hotel than to try to move the IETF around. For example this time if NANOG had been a month later it would have been in the same city yet different hotels. I understand that synchronized meetings it not trivial, but it is worth considering. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:10 PM To: Tony Hain Cc: nanog@merit.edu Subject: Re: protocols that don't meet the need... On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said: Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. The IETF apparently has some major scheduling problems as it is, because there are very few venues that can handle the number of people that show up *and* have the right mix of large rooms and many smaller break-out rooms. Trying to get it into a hotel opposite a NANOG would just exacerbate the problem. And there's nothing stopping NANOG types from joining an IETF working group and participating via e-mail - there's a large number of people who have contributed to the IETF process and never actually been sighted at an IETF meeting. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: protocols that don't meet the need...
Christian On Feb 14, 2006, at 4:47 PM, David Meyer wrote: Tony/all, I am not going to speak for the IETF, but why would they? Their meetings are already open, and to be globally fair the proposed coordinators would have to attend 3-5 extra meetings a year to cover all the ops groups. I am also not speaking for the IETF (IAB), but the IAB has undertaken the task of trying to bring a little of what's happening in the IETF to the operator community (and hopefully in the process engaging folks to come to the IETF). Now, while many in the IETF argue that there is no such thing as an operator community, I personally see it differently, and there are many of us who think that operator input is sorely missing from the IETF process. That is one of the reasons we did the NANOG 35 IPv6 multihoming BOF (and are doing the same at the upcoming apricot meeting). Hmm, well, when there is lots of vendor and academia involvement, no, there's no operator community presented in number of things I'm following in the IETF. Take manet, for example, I don't even know to begin where to inject operator concerns/requirements. :-/ Well taken. And further, I would say manet is more the rule than the exception in this respect. BTW, it took me years to become facile with the (IETF) process (if I'm even there now :-)). I can say that I had excellent mentoring (Randy and perhaps a few others), so that helped. Maybe we need something not as formal as an IETF liaison relationship, but perhaps something like that. More thinking required... I think this is as much an IETF issue as it is of the operator community. Operators need to devote time to IETF to make the work in the IETF most relevant to the operators needs. Yes, and this has always been an acute problem as long as I've been around. People have day (night, weekend jobs). Co-location of the meetings seems a possible way to start attacking one aspect that problem, with the understanding that perhaps travel isn't the biggest of the problems, but it is a non-trivial issue for many of us. Thanks for the great comments. Dave pgpqxxBWZHWN3.pgp Description: PGP signature
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
One of method missing is doing top down random walks of ip6.arpa. Mark
Re: protocols that don't meet the need...
On Tue, 14 Feb 2006 12:35:19 -0800, Tony Hain [EMAIL PROTECTED] said: A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. The real problem is that people have unrealistic expectations wrt the IETF. What happened to the engineering spirit that dominated the internet-community before it was invaded by telco-guys in the late 90s? A couple points: 1. IETF does not and should not innovate. 2. IETF never did, can not, will not and should not be expected to solve anyone's problem. Sound bad? Not really. The IETF's role is to preserve and protect technology for public consumption. If there's a problem, solve it. If the solution is any good it may have the potential to become a standard later, but the solution should always come first. There are plenty of organisations making paper-standards going nowhere. There's enough people trying to turn the IETF into another useless papermill already. Today there are IETF-standards in progress for which there exist no implementation. Not even experimental code. Such standards are most likely DOA, so why bother? OTOH, NANOG-people should be more involved in core engineering issues. Most nanog'ers, with the exception of those representing small companies which don't separate engineering from operations, belong in the engineering category anyway. The problem is to convince their L8+ that their company never will rule the world alone, and that it may be wise to let their engineers cooperate with competitors on the some of the big issues. //per -- Per Heldal http://heldal.eml.cc/
Re: protocols that don't meet the need...
David, On Feb 14, 2006, at 5:07 PM, David Meyer wrote: Hmm, well, when there is lots of vendor and academia involvement, no, there's no operator community presented in number of things I'm following in the IETF. Take manet, for example, I don't even know to begin where to inject operator concerns/requirements. :-/ Well taken. And further, I would say manet is more the rule than the exception in this respect. BTW, it took me years to become facile with the (IETF) process (if I'm even there now :-)). I can say that I had excellent mentoring (Randy and perhaps a few others), so that helped. Maybe we need something not as formal as an IETF liaison relationship, but perhaps something like that. More thinking required... Thanks for the feedback. I've been following manet as an interested party for a while, with no real mission other than tracking it for emerging technologies RD. Lately, job is architecting municipal wireless networks (which is really far more than what most people think of when they think Sbux style WISP hotspots). And I'm looking at the IETF for what's been worked out so far with respect to wireless routing protocols for example, and I just can't help sitting here scratching my head about how I would ever use what they've come up with so far. And right now, I really can't without major modifications it seems. And I find that really sad actually. And, don't get me wrong, but I'm not trying to bash them at all. I just think that real world operations needs and concepts like wholesale access aren't even anywhere near the radar screen it seems. And that somehow needs to be fixed. And, yes, municipal wireless is a roller coaster that's still gathering speed, so, expecting that everything's already grown and ready for us are thoroughly unrealistic. But! ;-) Right now the routing protocol on the mesh side will likely be proprietary for some time, which really isn't in the operator's best interest but that's what we have to work with. I/we have a substantial interest in this becoming more than an academic PhD thesis exercise, but something that can really be practically used in the real world. Now, there is stuff in the MPLS community, for example, that I've followed more or less closely for the past 7 yrs that might actually be fruitful, but it too requires substantial tailoring. So, no worries about job security there. ;-) I think this is as much an IETF issue as it is of the operator community. Operators need to devote time to IETF to make the work in the IETF most relevant to the operators needs. Yes, and this has always been an acute problem as long as I've been around. People have day (night, weekend jobs). Co-location of the meetings seems a possible way to start attacking one aspect that problem, with the understanding that perhaps travel isn't the biggest of the problems, but it is a non-trivial issue for many of us. Agreed. I'm headed to the IEEE 802 plenary in a couple of weeks to start working standards body stuff for us as well, some of what needs to happen is lower layer stuff. The less trips and the more I can combine them, the more likely my management will look at my travel expense submissions in a favorable light ;-).. So, the more incentive we can provide with that, the better. A while back, there was a desire to colo ARIN with NANOG. That's really cool to see happen. For me, no offense to anyone, I really couldn't care less at the moment. I'm on the opposite side of the spectrum, ARIN being a vehicle for operationalized networks rather than those who are about to be operationalized. So, perhaps NANOG should be paired up with other industry forums in some kind of rotation.. Anyone got ideas on this? Best regards, Christian
reg-ops now becoming fully operational
As originally sent to the registrars list by Rick Wesson... Through 2005, the reg-ops (Registrar Operations) mailing list which was established after the first Panix incident, was working by trial and error, learning from past mistakes, formalizing reporting guidelines and operating procedures. The mailing list now holds representatives from most of the big registrars. reg-ops also holds liaisons to NSP-SEC, DA/MWP, ICANN, SSAC, NANOG and the root servers. Other than the registrars, there are also a limited number of vetted individual from the anti-spam, anti-phishing and security industry. The purpose of the list is to relay reliable information in real-time from the industry to registrars on issues such as scams, phishing, etc. Real-time issues are handled with care while other reports can be made digested, periodically. The list is mostly operational and therefore there is not much chatter. However, security and operational issues which concern registrars or cooperation/information sharing happens when it is needed. The list is not open to the public, and subscription requires vetting. Please contact me or Gadi Evron [EMAIL PROTECTED] directly to be added to the group. Thanks, Gadi.
Re: reg-ops now becoming fully operational
On Wed, 15 Feb 2006, Gadi Evron wrote: As originally sent to the registrars list by Rick Wesson... Through 2005, the reg-ops (Registrar Operations) mailing list which was established after the first Panix incident, was working by trial and error, learning from past mistakes, formalizing reporting guidelines and operating procedures. The mailing list now holds representatives from most of the big registrars. reg-ops also holds liaisons to NSP-SEC, DA/MWP, ICANN, SSAC, NANOG and the root servers. Other than the registrars, there are also a limited number of vetted individual from the anti-spam, anti-phishing and security industry. The purpose of the list is to relay reliable information in real-time from the industry to registrars on issues such as scams, phishing, etc. Real-time issues are handled with care while other reports can be made digested, periodically. The list is mostly operational and therefore there is not much chatter. However, security and operational issues which concern registrars or cooperation/information sharing happens when it is needed. The list is not open to the public, and subscription requires vetting. Please contact me or Gadi Evron [EMAIL PROTECTED] directly to be added to the group. Please add - [EMAIL PROTECTED] -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: reg-ops now becoming fully operational
Sorry for last message that was supposed to be offline - forgot to remove list address. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: protocols that don't meet the need...
On Tue, 14 Feb 2006, Tony Hain wrote: A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. [Hm, what happened last night that I missed] I rather thought today's talk (last one in morning) by Randy Bush might have been pushed you to write this ... Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. You mean like NANOG and IETF both having meeting in Dallas? This will mean that people who regularly attend both will have overlap issues Its difficult enough to make it for one week for conference. Taking two weeks off for two conferences is too much to ask for must of us I think. , but if one meeting every year or two is joint there is an opportunity for those who can't justify the extra trips to at least have some feedback to try and close the loop on protocol design. I think better way is to have at least one track (from 2nd part of day) at NANOG devoted to IETF related issues. New BOFs that happen at IETF can be repeated at NANOG plus people from IETF might discuss current milestones and direction for workgroup of interest to those at NANOG. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On Wed, 15 Feb 2006, Mark Andrews wrote: One of method missing is doing top down random walks of ip6.arpa. That's only easy if delegation were on a per-nybble basis, which is commonly not the case. Because there are not typically NS's at every nybble level, you have to do more than one hex digit's worth of randomness in the scan in order to find a next-level delegation, increasing the cost of scanning that namespace quite a bit. (Having delegations at every nybble level would be ... alarming at best, given the amount of PTR redirection that implies. :) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On Wed, 15 Feb 2006, Mark Andrews wrote: One of method missing is doing top down random walks of ip6.arpa. That's only easy if delegation were on a per-nybble basis, which is commonly not the case. Because there are not typically NS's at every nybble level, you have to do more than one hex digit's worth of randomness in the scan in order to find a next-level delegation, increasing the cost of scanning that namespace quite a bit. (Having delegations at every nybble level would be ... alarming at best, given the amount of PTR redirection that implies. :) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I suggest that you re-read RFC 1034 and RFC 1035. A empty node returns NOERROR. A non-existant node returns NXDOMAIN (Name Error). e.a.e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa PTR drugs.dv.isc.org causes all of the following to exist. a.e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.1.0.7.4.0.1.0.0.2.ip6.arpa 1.0.7.4.0.1.0.0.2.ip6.arpa 0.7.4.0.1.0.0.2.ip6.arpa 7.4.0.1.0.0.2.ip6.arpa 4.0.1.0.0.2.ip6.arpa 0.1.0.0.2.ip6.arpa 1.0.0.2.ip6.arpa 0.0.2.ip6.arpa 0.2.ip6.arpa 2.ip6.arpa ip6.arpa arpa . A query for any of them regardless of type should return something other than NXDOMAIN. Also wildcards won't save you as it is possible to detect them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On Wed, 15 Feb 2006, Mark Andrews wrote:
One of method missing is doing top down random walks of ip6.arpa.
That's only easy if delegation were on a per-nybble basis, which is commonly
not the case. Because there are not typically NS's at every nybble level,
you have to do more than one hex digit's worth of randomness in the scan in
order to find a next-level delegation, increasing the cost of scanning that
namespace quite a bit.
(Having delegations at every nybble level would be ... alarming at best,
given the amount of PTR redirection that implies. :)
--
-- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
A simple demonstation program. Don't run it for too long
as we don't really want to beat on WIDE's servers.
Mark
#!/bin/sh
qname=1.0.0.2.ip6.arpa
depth=4
try() {
local newqname
local oldqname
local l
oldqname=$qname
for l in 0 1 2 3 4 5 6 7 8 9 a b c d e f
do
newqname=$l.$oldqname
echo trying $newqname
dig +noques ptr $newqname /tmp/$$xxx
grep PTR /tmp/$$xxx
if grep NOERROR /tmp/$$xxx /dev/null
then
qname=$newqname
if test $depth -lt 31
then
depth=`expr $depth + 1`
try
depth=`expr $depth - 1`
fi
fi
done
qname=$oldqname
}
try
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: Fed Bill Would Restrict Web Server Logs
Original posting from Declan McCullagh's PoliTech mailing list. Thought NANOGers would be interested since, if this bill passes, it would impact almost all of us. Just imagine the impact on security of not being able to login IP address and referring page of all web server connections! Seems to me that security would be a legitimate business purpose for keeping the information around. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpnpH8YSLGet.pgp Description: PGP signature
Re: NANOG36-NOTES 2006.02.14 talk 2 Netflow Visualization Tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 thanks for taking notes. comments in-line: Matthew Petach wrote: 2006.02.14 talk 2 Netflow tools Bill Yurcik byurcik at ncsa.uiuc.edu NVisionIP and VisFlowConnect-IP probably a dozen tools out there, this is just two of them. Concenses is there's something to this. They're an edge network, comes into ISP domain, their tools are used by entities with many subnet blocks. Overview Project Motifivation Netflows for Security Two visualization tools NVisionIP VisFlowConnect-IP Summary Internet Security: N-Dimensional Work Space large--already lots of data to process complex--combinatorics explode quickly time dynamics--things can change quickly! Visualizations can help! in near-realtime overview-browse-details on demand People are wired to do near-realtime processing of visual information, so that's a good way to present information for humans. HCI says use overview-browse-details paradigm. Netflows for security can identify connection-oriented stats to see things like attacks, DoS, DDoS, etc. Most people don't use the data portion of the flow field, the first 64 bytes, they just look at header info or aggregated flow records. Can spot how many users are on your system at a given time, to schedule upgrades. Who are your top talkers? How long do my users surf? What are people using the network for? Where do users go? Where did they come from? Are users following the security policy? What are the top N destination ports? Is there traffic to vulnerable hosts? Can you identify and block scanners/bad guys? This doesn't replace other systems like syslog, etc.; it integrates and works alongside them. architecture slide for NCSA. Can't really do sampled view for security, so probably need distributed flow collector farm to get all the raw data safely. Two visualization tools: NVisionIP, VisFlowConnect-IP focus on quick overview of tools security.ncsa.uiuc.edu/ 3 level hierarchical tool; galaxy view (small multiple view) ((machine view)) Galaxy is overview of the whole network. color and shape of dots is each host in a network. settable parameters for each dot. Animated toolbar and clock show changes over time in the galaxy. Lets you get high-level content quickly and easily. Domain view lets you drill in a bit more; small multiple view looks at the traffic within the block. upper histogram is lower, well known ports; lower histogram is ports over 1024 You can click on a given multiple view entry to delve into one machine. Many graphs for each machine in the most detailed view. well known ports first, then rest of ports (sorted) then source and destination traffic broken out. Designed for class Bs. http://security.ncsa.uiuc.edu/distribution/VisFlowConnectDownload.html 3 vertical lines, comes from edge network perspective; middle line is edge network to manage. You set range of networks you care about. Outside lines are people sourcing or sinking traffic to you, from outside domains. There's a time axis, traffic only shown for the slice of time currently under consideration. Uses VCR-like controls to move time forward/backward Lets you see traffic/interactivity, drill into that domain, see host level connectivity flows. Shows MS Blaster virus traffic as an example. Example 2, a scan example. Just because it looks like one IP hitting many others doesn't mean it's really a security incident, though; could be a cluster getting traffic. web crawlers hitting NCSA web servers make for a very charateristic pattern over time. Summary Netflows analysis is non-trivial, NVisionIP VisFlowConnect-IP lots of references listed in very fine blue font. http://security.ncsa.uiuc.edu/distribution/NVisionIPDownload Avi Freedman, Akamai, Argus was mentioned a lot; it lets you grab symmetric netflows, but also does TCP analysis, shows some performance data as well. not sure if people are studying the impact of correlating argus data with flow data. Roland Douta? of Cisco; many people are using netflow to track security issues. They now have ingress and egress flow data on many of their platforms. In reading paper describing it, there's data conversion that needs to happen into an internal format that nVision can understand. It reads log files at the moment, takes about 5 minutes to process files. Lets them take different file data sources, make the tool for visualization independent of the input format. They can read large files, but there is a performance hit when doing it. Are they planning on doing further work on the tool to collect TCP flags, for frags, drop traffic, etc? They've looked at it, but they leave it to IDS tools for flag activity. Might be of interest to consider for future versions of the tools. Last question came up, echoed about argus. Question about
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On Wed, 15 Feb 2006, Mark Andrews wrote: I suggest that you re-read RFC 1034 and RFC 1035. A empty node returns NOERROR. A non-existant node returns NXDOMAIN (Name Error). Right. This means depth-first walk, which will reduce the *possible* address space to probe, but that is the antithesis of traditional scanning (which is often at least partly stochastic). To a worm, the benefit of stochastic scanning is that no collaboration between infected hosts is needed; but with a walking traversal, you have to have some kind of statekeeping if the walk search is not intended to take ~forever. I can see this vector as being useful for scanning within some specific organization's subnet, but even then, you'll need some kind of collaboration with NDP solicitations for most internal setups. Stateless autoconfig, for instance, is unscannable without listening for NDP at the same time -- and from a remote network, you can basically forget it. You're also assuming that there will be PTR records for the most commonly infectable OS ([vendor product elided]) in the most commonly used configuration (desktop). It's highly likely that such systems will use some sort of autoconfiguration, and stateless form as above presents a fairly large address space to scan. If there are PTRs assigned for such hosts at all, the attack vector is actually somewhat simple to minimize: have the DNS product in use return empty NOERROR, rather than NXDOMAIN, for any unassigned addresses in the /64. Don't get me wrong, I'm not one for security through obscurity in the primary case. But attack vector minimization is still useful for this particular angle. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
NANOG36 Wednesday schedule, lightning talks
Here is the revised NANOG36 agenda for Wednesday, Feb. 15: 9:00-9:30v6fix: Wiping the Slate Clean for IPv6 Kenjiro Cho, WIDE/IIJ, Ruri Hiromi, WIDE/Intec NetCore 9:30-10:00 Hurricane Katrina: Telecom Infrastructure Impacts, Solutions, and Opportunities Paula Rhea, Verizon 10:00-10:30 Katrina Recover Panel moderator: Sean Donelan, Cisco 10:30-11:00 BREAK 11:00-11:20 An Inter-domain Consistency Management Layer Nate Kushman, MIT 11:20-12:20 Lightning Talks: Infrastructure (DNS and Routing) Security - Status and Update by Sandra Murphy Need for Speed: What's next after 10GE? by Mike Hughes A Brief Look at Some DNS Query Data by John Kristoff The impact of fiber access to ISP backbones in .jp by Kenjiro Cho New Network Monitoring Interest Group by Mike Caudill Understanding the Network-Level Behavior of Spammers by Nick Feamster (presented by Randy Bush) 12:20-12:30 Closing Remarks Steve Feldman, CNET, Susan Harris, Merit
Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
On Wed, 15 Feb 2006, Mark Andrews wrote: I suggest that you re-read RFC 1034 and RFC 1035. A empty node returns NOERROR. A non-existant node returns NXDOMAIN (Name Error). Right. This means depth-first walk, which will reduce the *possible* address space to probe, but that is the antithesis of traditional scanning (which is often at least partly stochastic). To a worm, the benefit of stochastic scanning is that no collaboration between infected hosts is needed; but with a walking traversal, you have to have some kind of statekeeping if the walk search is not intended to take ~forever. I can see this vector as being useful for scanning within some specific organization's subnet, but even then, you'll need some kind of collaboration with NDP solicitations for most internal setups. Stateless autoconfig, for instance, is unscannable without listening for NDP at the same time -- and from a remote network, you can basically forget it. And I expect that machines using stateless autoconfig will update their forward and reverse records in the DNS. The reasons for doing this are independent of the mechanism of address assignment. Too many services will not work unless there is a valid PTR / address combination. You're also assuming that there will be PTR records for the most commonly infectable OS ([vendor product elided]) in the most commonly used configuration (desktop). It's highly likely that such systems will use some sort of autoconfiguration, and stateless form as above presents a fairly large address space to scan. If there are PTRs assigned for such hosts at all, the attack vector is actually somewhat simple to minimize: have the DNS product in use return empty NOERROR, rather than NXDOMAIN, for any unassigned addresses in the /64. Don't get me wrong, I'm not one for security through obscurity in the primary case. But attack vector minimization is still useful for this particular angle. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
NANOG36-NOTES 2006.02.14 Tools BOF Notes
Last notes of the day... Matt 2006.02.14 Tools BOF Todd Underwood, panel moderator A number of interesting tools presented earlier today; all of them are good and interesting and solve a particular set of problems. None are in widespread use. There's a lot of possible reasons; do they solve problems you don't have, in which case they can move onto something new; or they solve a problem similar to one you have, but not quite. Or they solve a problem you can't quite implement yet. Discuss use cases, problems they're trying to solve, and give feedback, as interactively as comfortably as people can. 3 tools, OpenBGPD, IRR powertools/webtools (to get feedback and is the IRR even useful anymore?) and Flamingo as one of 2 netflow platforms. Start with Henning, active in open source software development; he'll go in more depth on openbgpd. OpenBGPD Henning Brauer henning at openbsd.org 3 process design Principle of least privilege the RDE (route decision engine) does not need any special priv at all, so it runs as __bgpd:__bgpd: chrooted to /var/empty SE needs to bind to TCP/179 parent needs to modify kernel routing table. Session Engine (SE) needs to bind to 179/tcp we have the parent open sockets see recvmsg(2) parent needsd to keep track of which fds the SE has open, so it doesn't bind() again to same ip/port the SE can drop all privs, then. SE 2 since one process handles all bgpd, need nonblocking sockets. on blocking, you call write(2), won't reurn until it's done or get errors on nonblocking, returns as soon as it can't proceed immediately So, have to handle buffer managmeent SE 3 designed an easy to use buffer API and mesg handling system. Messaging internal messaging is core comp. in reused for OpenNTPD, OPenOSPFD, and somee more. bgpd has more than 52 message types, more than OpenSSH bgpctl talks to bgpd using same imsg socket tcp md5 some very old code in kernel for tcp md5, from 4.4 BSD never worked tcp md5 is somewhat similar to ipsec, ah, so implement it within IPSec maze. Had to add pfkey interface to bgpd; committee designed API. that made IPSec that much easier; extended the API so they can request unused SPIs from kernel, don't have to be configured manually. tcp md5/ipsec when you don't have tcp md5 or ipsec in place, big tcp windows are risky stay at 16k window unless you have tcp md5 or ipsec, then you get 64K so ipsec improves performance. Joel Yagli asks how big a tcp window do you need for a BGP session at all? initial connection gets faster with 64K, but thereafter, similar. looking glass just added an optional second control socket that is restricted to the show operations regular bgpctl binary can be used with it cgi, yeah, that needs to be hacked in shape, but it's easy. Juniper only does static IPSec setup, so requires nasty setup. OpenBGPD is dynamic, but interoperates with Junipers. So back to looking glass, security on OpenBSD, the httpd (an apache 1.3 variant) runs in a chroot jail by default th readonly socket can be placed inside that jail bgpd_flags=-r /var/www/bgpd.rsock in rc.conf.local put a statically linked bgpctl binary in the chroot /path/to/bgpctl -s /bgp.rsock, $ impressions from road to ipv6 most heinous checkin message yet. The lower 2 bytes of the scopeID overwrite part of the v6 address...ugly! Performance http://hasso.linux.ee/linux/openbgpd.php it's quick openBGPD 3.6 port for linux; can't communicate with kernel, no v6, no md5; 8 times faster than quagga. future plans and ideas the biggest task waits outside bgpd itself; kernel routing table. we need to make use of the radix mpath capabilities added in 2004, and add route source markers (BGP, OSPF, etc) bgpd and ospfd can blindly install their routes kernel then knows precedence hard to do, once it's done, routing will be easier. Also need multiple routing tables, with pf acting as table selector so unholy route-to can died, and associated issues vanish/ might be useful with bgpd as well. iddeas for quite radical changs, speed up packet forwarding dramatically. will have fast path where all easy cases can be handled on specialized PCI cards multiple 10GE at wire speed within 2 years. hardware exists, on way to him. for route servers, reversing filter and best path selection would be good. filter generation from RIPE DB or similar but IRR toolset sucks hairy moose balls should be solvable in perl someone has to code it. (maybe use IRR power tools for it instead!) [ we can fail over IP addresses already, thanks to CARP we can hve synchronized state tables on multiiple machines, gives HA firewall clusters. Would be really cool to be able to fail over TCP sessions and bgp sessions. could make for BGP hitless failover syncging BGP stuff shouldn't be too hard lots of work, not much time. Money has to come from somewhere, obviously. Unfortunately, people forget about this, just go to mirrors. Vendors don't help Never got anything for OpenSSH yet it comes down to you. yes
Re: IRS goes IPv6!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher L. Morrow wrote: On Tue, 14 Feb 2006, Jeroen Massar wrote: I Ar Es, At least they have received the 2610:30::/32 allocation from ARIN. Lets see if they how taxing they find IPv6 ;) so.. this is surprising why? the us-gov mandate for ipv6 uptake will mean lots of us-gov folks will be spinning up justifications that they are a 'service provider' and need a /32... cause they won't accept PA space (or I don't think they will accept PA space as a long term solution) ... or I might be smoking crack :) who knows. - -- resistance is futile, you will be assimilated :-) regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8sY0pbZvCIJx1bcRAu6vAJ0dlSiJvkDWkXtZ1oHIRZQrNRHqdACgscec 2GCg+nM2inuo62oBau4KEh0= =bK4r -END PGP SIGNATURE-
Re: NANOG36-NOTES 2006.02.14 talk 2 Netflow Visualization Tools
Roland Dobbins - that's me asking about the time intervals for the bins and the TCP flags stuff. ; Note that 5-minute bins may not always be optimal for opsec - 5 minutes minimum to see something happening and then 5 minutes to see if your mitigation action was effective is a long time. With NetFlow- based anomaly-detection systems, the active flow timeout value is generally turned down to one minute; the operator may -choose- to suppress certain types of alarms for a set period, or configure threshold-transition delays, but being stuck at a practical minimum of 10 minutes between detection and confirmation of mitigation due to data-conversion overhead (the collected flow telemetry must be converted into another format prior to analysis) may be an issue, in some circumstances. On Feb 14, 2006, at 8:13 PM, Vicky Røde wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 thanks for taking notes. comments in-line: Matthew Petach wrote: 2006.02.14 talk 2 Netflow tools Bill Yurcik byurcik at ncsa.uiuc.edu NVisionIP and VisFlowConnect-IP probably a dozen tools out there, this is just two of them. Concenses is there's something to this. They're an edge network, comes into ISP domain, their tools are used by entities with many subnet blocks. Overview Project Motifivation Netflows for Security Two visualization tools NVisionIP VisFlowConnect-IP Summary Internet Security: N-Dimensional Work Space large--already lots of data to process complex--combinatorics explode quickly time dynamics--things can change quickly! Visualizations can help! in near-realtime overview-browse-details on demand People are wired to do near-realtime processing of visual information, so that's a good way to present information for humans. HCI says use overview-browse-details paradigm. Netflows for security can identify connection-oriented stats to see things like attacks, DoS, DDoS, etc. Most people don't use the data portion of the flow field, the first 64 bytes, they just look at header info or aggregated flow records. Can spot how many users are on your system at a given time, to schedule upgrades. Who are your top talkers? How long do my users surf? What are people using the network for? Where do users go? Where did they come from? Are users following the security policy? What are the top N destination ports? Is there traffic to vulnerable hosts? Can you identify and block scanners/bad guys? This doesn't replace other systems like syslog, etc.; it integrates and works alongside them. architecture slide for NCSA. Can't really do sampled view for security, so probably need distributed flow collector farm to get all the raw data safely. Two visualization tools: NVisionIP, VisFlowConnect-IP focus on quick overview of tools security.ncsa.uiuc.edu/ 3 level hierarchical tool; galaxy view (small multiple view) ((machine view)) Galaxy is overview of the whole network. color and shape of dots is each host in a network. settable parameters for each dot. Animated toolbar and clock show changes over time in the galaxy. Lets you get high-level content quickly and easily. Domain view lets you drill in a bit more; small multiple view looks at the traffic within the block. upper histogram is lower, well known ports; lower histogram is ports over 1024 You can click on a given multiple view entry to delve into one machine. Many graphs for each machine in the most detailed view. well known ports first, then rest of ports (sorted) then source and destination traffic broken out. Designed for class Bs. http://security.ncsa.uiuc.edu/distribution/ VisFlowConnectDownload.html 3 vertical lines, comes from edge network perspective; middle line is edge network to manage. You set range of networks you care about. Outside lines are people sourcing or sinking traffic to you, from outside domains. There's a time axis, traffic only shown for the slice of time currently under consideration. Uses VCR-like controls to move time forward/backward Lets you see traffic/interactivity, drill into that domain, see host level connectivity flows. Shows MS Blaster virus traffic as an example. Example 2, a scan example. Just because it looks like one IP hitting many others doesn't mean it's really a security incident, though; could be a cluster getting traffic. web crawlers hitting NCSA web servers make for a very charateristic pattern over time. Summary Netflows analysis is non-trivial, NVisionIP VisFlowConnect-IP lots of references listed in very fine blue font. http://security.ncsa.uiuc.edu/distribution/NVisionIPDownload Avi Freedman, Akamai, Argus was mentioned a lot; it lets you grab symmetric netflows, but also does TCP analysis, shows some performance data as well. not sure if people are studying the impact of correlating argus data with flow data. Roland Douta? of Cisco; many people are using netflow to track security issues. They now have ingress and egress flow data on many of
FYI: reg-ops now becoming fully operational
Through 2005, the reg-ops (Registrar Operations) mailing list which was established after the first Panix incident, was working by trial and error, learning from past mistakes, formalizing reporting guidelines and operating procedures. The mailing list now holds representatives from most of the big registrars. reg-ops also holds liaisons to NSP-SEC, DA/MWP, ICANN, SSAC, NANOG and the root servers. Other than the registrars, there are also a limited number of vetted individual from the anti-spam, anti-phishing and security industry. The purpose of the list is to relay reliable information in real-time from the industry to registrars on issues such as scams, phishing, etc. Real-time issues are handled with care while other reports can be made digested, periodically. The list is mostly operational and therefore there is not much chatter. However, security and operational issues which concern registrars or cooperation/information sharing happens when it is needed. The list is not open to the public, and subscription requires vetting. Please contact me or Gadi Evron [EMAIL PROTECTED] directly to be added to the group. Thanks, -rick
