Re: [ncc-services-wg] Incident Response Service (IRS) [was: Unneeded RIPE tasks] (fwd)
Dear Wilfried, Hank, On Fri, 22 Aug 2003, Wilfried Woeber, UniVie/ACOnet wrote:
Section 5: "Incident Response Service (IRS) Procedures will be set up to quickly provide RIPE NCC members, the Internet community and the general public with authoritative data about unusual events on the Internet, such as DDoS on the RIPE NCC."
I wrote this sentence and the paragraphs before them and, with all due respect, but I think that Hank cut away too much text here.
1) can we have a more elaborate description from the NCC of what activities are expected to be performed under this headline?
These lines are part of a larger piece of text describing the Information Services (IS) activity. The goal of the IS activity is to collect statistical data on the Internet, ranging from individual providers (for example, RIS and TTM) via policy making groups (AP-WG on usage of resources), the Internet community (for example: number of AS's and prefixes seen) to the general public. Collecting the data alone is not sufficient, of course, we also want to make sure that the statistics we collect reaches the appropriate people in a timely manner. A subset of the IS activity is therefore to have procedures in place to distribute reports on data (analysis) quickly if the need arises. It is obviously not a goal to repeat what others are already doing quite well. However, the RIPE NCC has data that others do not have, and this we want to distribute. For example, earlier this year, we published a report on the impact of the sapphire worm on the Internet. Another example is a recent discussion on heise.de, on the unreachability on the .at ccTLD from the Telecom Austria network, involving some fingerpointing. NIC.AT already published the plots, but this could have been another case where we'd publish our data in order to (in)validate a claim.
2) is there any WG which could be polled or which has "adopted" this activity for definition and development (or is expected to do so)?
As soon as the AP2004 is approved, we (Daniel K and myself) will write an implementation document, describing the activities proposed under section 5 in more detail. This document will be circulated to, I'd guess, the services-WG and discussed there. Cheers, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)
On Mon, 25 Aug 2003, Henk Uijterwaal (RIPE-NCC) wrote:
For example, earlier this year, we published a report on the impact of the sapphire worm on the Internet.Another example is a recent discussion on heise.de, on the unreachability on the .at ccTLD from the Telecom Austria network, involving some fingerpointing.NIC.AT already published the plots, but this could have been another case where we'd publish our data in order to (in)validate a claim.
I do not see ARIN or APNIC entered these kind of areas that are not "registration" orienated and as time moves on it would appear more and more RIPE services are not registration orienated.
2) is there any WG which could be polled or which has "adopted" this activity for definition and development (or is expected to do so)?
As soon as the AP2004 is approved, we (Daniel K and myself) will write an implementation document, describing the activities proposed under section 5 in more detail.This document will be circulated to, I'd guess, the services-WG and discussed there.
And you do not see this a procedurally wrong? Wherever I work, whenever they want to do "something new", they need to write it up fully, indicate the budget and manpower needed and then submit to management. Based on that info, management can make an intelligent decision. Instead, we have 1 paragraph describing what will be done in general and once the AP2004 is approved based on that, only then do we find out how much all this cost. I don't know a single company that works like this.
Cheers,
Henk
------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------
That problem that we weren't having yesterday, is it better? (Big ISP NOC)
Hank Nussbacher
Dear Hank,
2) is there any WG which could be polled or which has "adopted" this activity for definition and development (or is expected to do so)?
As soon as the AP2004 is approved, we (Daniel K and myself) will write an implementation document, describing the activities proposed under section 5 in more detail.This document will be circulated to, I'd guess, the services-WG and discussed there.
And you do not see this a procedurally wrong? Wherever I work, whenever they want to do "something new", they need to write it up fully, indicate the budget and manpower needed and then submit to management. Based on that info, management can make an intelligent decision.
I've seen this approach. I've also worked at places where the LOI/TDR approach was used: the first document ("Letter of Intent") gave a global outline of the activity, goals, deadlines, costs, manpower, etc. Only when this was approved, a second document ("Technical Design Report") was written discussing all the details. I personally believe that this approach makes much more sense, why waste time/money to work out details _before_ there is consensus that the activity should be persued in the first place.
Instead, we have 1 paragraph describing what will be done in general and once the AP2004 is approved based on that, only then do we find out how much all this cost.
This is not correct. There is indeed only one paragraph in the AP2004, due to space constraints. However, there is also the strategy paper: http://www.ripe.net/ripe/docs/hostcount.html with more details about the IS activity. This paper was discussed at RIPE45 and people have been invited to comment on this document on the tt-wg@ripe.net list. Then the proposed budget: http://www.ripe.net/ripe/draft-documents/budget2004-aoa97.html and http://www.ripe.net/ripe/draft-documents/budget2004-aoa03.html does contain an estimated budget for this activity. If you have any specific questions about the 2 documents mentioned above, I suggest that we take them to the tt-wg@ripe.net list. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)
At 10:35 AM 25-08-03 +0200, Henk Uijterwaal (RIPE-NCC) wrote:
Dear Hank,
And you do not see this a procedurally wrong? Wherever I work, whenever they want to do "something new", they need to write it up fully, indicate the budget and manpower needed and then submit to management. Based on that info, management can make an intelligent decision.
I've seen this approach. I've also worked at places where the LOI/TDR approach was used: the first document ("Letter of Intent") gave a global outline of the activity, goals, deadlines, costs, manpower, etc. Only when this was approved, a second document ("Technical Design Report") was written discussing all the details. I personally believe that this approach makes much more sense, why waste time/money to work out details _before_ there is consensus that the activity should be persued in the first place.
I would have been very happy to see an LOI/TDR approach where a global outline would contain just costs and manpower. No such document on IRS has ever been presented.
Instead, we have 1 paragraph describing what will be done in general and once the AP2004 is approved based on that, only then do we find out how much all this cost.
This is not correct. There is indeed only one paragraph in the AP2004, due to space constraints. However, there is also the strategy paper:
A title of "RIPE NCC Hostcount in the 21st Century - A New Direction for Measurements by the RIPE NCC" does not give any indication of Incident Response content, sorry. Including security inside a hostcount document is wrong. I would have thought that the techseg-wg would be far more appropriate to discuss an Incident Response Service.
with more details about the IS activity. This paper was discussed at RIPE45 and people have been invited to comment on this document on the tt-wg@ripe.net list. Then the proposed budget:
The test-Traffic WG, as per its charter states: "The purpose of the Test Traffic Measurements is to independently measure the performance parameters of the Internet using test traffic boxes located in the networks of participating ISP's. ... Although the working group was set up as a result of the test traffic project the scope of the group should allow any new performance measuring techniques to be included and proposals for such devices are most welcome. The data collected is analysed for the purpose of network trouble shooting, capacity planning and other such worthwhile reports. It is not the purpose of the working group to compare different ISP's network performance nor should the data be used for marketing purposes of any kind." Nothing about Incident Response.
http://www.ripe.net/ripe/draft-documents/budget2004-aoa97.html and http://www.ripe.net/ripe/draft-documents/budget2004-aoa03.html
does contain an estimated budget for this activity.
No it does not! It contains an aggregated budget of 1.4Meuro for Information Services with no indication of manpower. In addition, Information Services, based on http://www.ripe.net/ripe/draft-documents/ap2004.html includes from section 5: RIS, AMS, SCS, and IRS. There is *NO* way to know how much IRS will take in budget or manpower.
If you have any specific questions about the 2 documents mentioned above, I suggest that we take them to the tt-wg@ripe.net list.
I went thru the archives of the tt-wg and found nothing being discussed about Incident Response Service. The two above documents you list: RIPE NCC Budget 2004 has very little to do with the tt-wg and much more with the ncc-services WG. -Hank
Henk
------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------
That problem that we weren't having yesterday, is it better? (Big ISP NOC)
Dear Hank, For your first question, please see Daniel's quote from RIPE271 and further text in his posting earlier today.
with more details about the IS activity. This paper was discussed at RIPE45 and people have been invited to comment on this document on the tt-wg@ripe.net list. Then the proposed budget:
The test-Traffic WG, as per its charter states: [...]
Speaking as the former chair of the tt-wg: Formally speaking you are right, it is outside the charter of the TT-WG. However, after Daniel's presentation at RIPE45 and subsequent discussion, the question was raised where further comments on the topic could be posted. As the IS activity overlaps between at least 5 different WG's (tt, techsec, services, routing, DNS*) and none of them is exactly the right place for this discussion, we arbitrarily picked the tt-wg list. There haven't been that many postings on the topic as I'd hoped, but comments are still welcome. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)
I've seen this approach. I've also worked at places where the LOI/TDR approach was used: the first document ("Letter of Intent") gave a global outline of the activity, goals, deadlines, costs, manpower, etc. Only when this was approved, a second document ("Technical Design Report") was written discussing all the details. I personally believe that this approach makes much more sense, why waste time/money to work out details _before_ there is consensus that the activity should be persued in the first place.
Maybe we should adapt this kind of procedure ? At some time prior to making the plan LOIs are circulated to the list/members for support. When there is sufficient support for the proposal it will be included in the activity plan The result would be a RIPE NCC activity plan established trough comunity consensus rather than the RIPE NCC management proposed activity plan. -hph
Another new service I'd like to discuss is the TTM ip2asn service as presented at RIPE-46: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tracero... I know of 4 other methods for doing ip2asn conversions (permission received from each to supply this info): -------------------------------------- From: robt@cymru.com We have one that is somewhat quick and really very dirty. :) I've shared it with a few folks, so I'll share it with the full list now. It depends on the Perl Cisco Telnet module and access to a BGP-savvy router. You will find it at the following URL: <http://www.cymru.com/Tools/getorgasn2.pl> It's not pretty, but it works. Feel free to modify it as you see fit, and you may share it with anyone. Comments welcome! Thanks, Rob, for Team Cymru. -- Rob Thomas -------------------------------------- From: j.green@ukerna.ac.uk First you need a source of routing information (http://archive.routeviews.org/) This then needs to be parsed. I either use parse_bgp_dump from CAIDA (and run "'sh ip bgp' format RIBs" through it), or use http://www.bugged.org/download/misc/bgpparser.c (after tweaking the defines to extract the correct fields) and pass "MRT format RIBs" through it. CAIDA merges multipleorigins into a generic entry, whereas bgpparser creates multiple entries. Either way you want a file with a.b.c.d/e AS ... a.b.c.d/e AS Then use something like Net::Patricia to lookup the AS for an IP address. The only slow thing seems to be reading in the file into memory (I guess you could daemonise it, or use a more parse efficient storage format it this matters). There is some scripts from a while back at http://kaizo.us/girona/bgp/ bgpparse.tar is the relevant bits out of CAIDA's larger package. aslookup.pl is very simple perl script route-table is a parsed version of the data from routeviews from June. Hope this helps John JANET-CERT ------------------------------------------- From: joe@oregon.uoregon.edu Because a number of people have expressed an interest in an IP->ASN DNS zone, if you're interested, the Routeviews project now has a test/static asn zone up that you can try, e.g.: % dig @archive.routeviews.org 13.142.223.128.asn.routeviews.org txt [snip] ;; ANSWER SECTION: 13.142.223.128.asn.routeviews.org. 86400 IN TXT "3582" [snip] % dig @archive.routeviews.org 109.131.229.169.asn.routeviews.org txt [snip] ;; ANSWER SECTION: 109.131.229.169.asn.routeviews.org. 86400 IN TXT "25" [snip] That was the original format. It now works as follows: % host -t txt 35.32.223.128.asn.routeviews.org 35.32.223.128.asn.routeviews.org text "3582" "128.223.0.0" "16" In addition to being able to get the stub ASN, a second zone will also let you get the AS path associated with a specific dotted quad. For example: % host -t txt 122.3.15.66.aspath.routeviews.org 122.3.15.66.aspath.routeviews.org text "2497 3356 1 189" "66.15.3.0" "24" 122.3.15.66.aspath.routeviews.org text "2497 3356 1" "66.15.0.0" "17" In parsing what's returned, be sure to plan to accomodate the possibility that you may get multiple records returned for a single query. Thanks, Joe St Sauver (joe@oregon.uoregon.edu) University of Oregon Computing Center ----------------------------------------------- From: gillsr@yahoo.com www.qorbit.net/code/ip2asn-v1.1.tar.gz ip2asn-coral.pl - very fast, uses Caida's Coral Reef package, requires route table dump. Initial load takes a bit to read route-file. ip2asn-server.pl - slower, requires a route-server, preferably one that supports 'show ip bgp $ip/32 shorter' syntax. --------------------------------------------- Can the RIPE NCC TTM group explain why such a service is needed when there are other packages available that do similar things? Slide #2 seems to state that you want a traceroute that includes the ASN. Slide #14 states "RIPE-NCC will set up an IP-AS mapping service with something like "traceroute -A". How will this be different than a standard traceroute from any Cisco router: TAU-gp1#trace www.cisco.com Translating "www.cisco.com"...domain server (128.139.6.1) [OK] Type escape sequence to abort. Tracing the route to www.cisco.com (198.133.219.25) 1 iucc.il1.il.geant.net (62.40.103.225) [AS 20965] 0 msec 0 msec 0 msec 2 il.nl1.nl.geant.net (62.40.96.117) [AS 20965] 68 msec 64 msec 68 msec 3 nl.de1.de.geant.net (62.40.96.101) [AS 20965] 72 msec 72 msec 72 msec 4 so-7-0-0.ar2.FRA2.gblx.net (208.48.23.145) [AS 3549] 72 msec 72 msec 72 msec 5 pos5-0-2488M.cr2.FRA2.gblx.net (67.17.65.53) [AS 3549] 72 msec 72 msec 72 msec 6 so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38) [AS 3549] 84 msec 80 msec 80 msec 7 so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30) [AS 3549] 88 msec 84 msec 80 msec 8 sl-bb21-lon-1-3.sprintlink.net (213.206.131.25) [AS 1239] 88 msec 88 msec 88 msec 9 sl-bb21-tuk-10-0.sprintlink.net (144.232.19.69) [AS 1239] 164 msec 164 msec 164 msec 10 sl-bb20-tuk-15-0.sprintlink.net (144.232.20.132) [AS 1239] 164 msec 164 msec 168 msec 11 sl-bb21-rly-15-1.sprintlink.net (144.232.20.120) [AS 1239] 168 msec 172 msec 164 msec 12 sl-bb23-rly-11-0.sprintlink.net (144.232.14.134) [AS 1239] 164 msec 176 msec 168 msec 13 sl-bb20-rly-9-0.sprintlink.net (144.232.14.117) [AS 1239] 176 msec 168 msec 172 msec 14 sl-bb25-sj-5-3.sprintlink.net (144.232.20.57) [AS 1239] 296 msec 228 msec 228 msec 15 sl-gw11-sj-10-0.sprintlink.net (144.232.3.134) [AS 1239] 232 msec 228 msec 232 msec 16 sl-ciscopsn2-11-0-0.sprintlink.net (144.228.44.14) [AS 1239] 220 msec 220 msec 224 msec 17 sjce-dirty-gw1.cisco.com (128.107.239.89) [AS 109] 228 msec 224 msec 224 msec 18 sjck-sdf-ciod-gw2.cisco.com (128.107.239.102) [AS 109] 228 msec 228 msec 228 msec 19 * www.cisco.com (198.133.219.25) [AS 109] 236 msec * Thanks, Hank
Hi Hank, Just a quick word of clarification on the AS scripts: 1. getorgasn2.pl is included inside ip2asn-v1.1.tar.gz. The AS conversion scripts include an ONLINE (route-server) and an OFFLINE (bgp table dump) version. There are three scripts in the tar.gz. 2. RE: the e-mail From: j.green@ukerna.ac.uk, one of the scripts above does exactly this using Caida's CoralReef package. 3. RE: Slide #2, lft is a traceroute program for windows/unix that does exactly this: maps IPs to AS numbers. You can download it here: http://www.mainnerve.com/lft/ Ex: su-2.05b# lft -A 4.2.2.1 Tracing _____________________________________________________________________. TTL LFT trace to vnsc-pri.sys.gtei.net (4.2.2.1):80/tcp 1 [AS5102] gw-sbc.as23028.net (68.22.187.1) 20.4ms 2 [AS5102] 65.42.139.41 20.0ms 3 [AS5102] bb2-g5-0.chcgil.ameritech.net (67.38.101.116) 19.6ms 4 [ASN?] sl-gw38-chi-13-0.sprintlink.net (160.81.109.237) 19.7ms 5 [AS1239] sl-bb20-chi-4-0.sprintlink.net (144.232.26.129) 19.5ms 6 [AS1239] sl-bb21-chi-8-0.sprintlink.net (144.232.26.78) 59.6ms 7 [AS1239] sl-st20-chi-15-1.sprintlink.net (144.232.20.80) 19.4ms 8 [AS3356] so-2-1-0.edge1.Chicago1.Level3.net (209.0.225.21) 20.0ms 9 [AS3356] so-2-1-0.bbr1.Chicago1.level3.net (209.244.8.9) 20.0ms 10 [AS3356] so-1-0-0.bbr1.Atlanta1.level3.net (209.247.9.106) 40.4ms 11 [AS3356] pos8-0.hsa1.Atlanta1.Level3.net (209.247.9.166) 40.4ms 12 [AS3356] vlan521.public-msf1.Atlanta2.Level3.net (67.72.92.18) 40.4ms ** [neglected] no reply packets received from TTLs 13 through 25 26 [prohibited] [AS3356] vlan521.public-msf1.Atlanta2.Level3.net (67.72.92.18) 40.4/*ms Cheers, -- steve -----Original Message----- From: Hank Nussbacher [mailto:hank@att.net.il] Sent: Wednesday, September 10, 2003 3:19 AM To: ncc-services-wg@ripe.net Cc: robt@cymru.com; j.green@ukerna.ac.uk; joe@oregon.uoregon.edu; gillsr@yahoo.com Subject: New service: ip2asn Another new service I'd like to discuss is the TTM ip2asn service as presented at RIPE-46: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra ceroutes.pdf I know of 4 other methods for doing ip2asn conversions (permission received from each to supply this info): -------------------------------------- From: robt@cymru.com We have one that is somewhat quick and really very dirty. :) I've shared it with a few folks, so I'll share it with the full list now. It depends on the Perl Cisco Telnet module and access to a BGP-savvy router. You will find it at the following URL: <http://www.cymru.com/Tools/getorgasn2.pl> It's not pretty, but it works. Feel free to modify it as you see fit, and you may share it with anyone. Comments welcome! Thanks, Rob, for Team Cymru. -- Rob Thomas -------------------------------------- From: j.green@ukerna.ac.uk First you need a source of routing information (http://archive.routeviews.org/) This then needs to be parsed. I either use parse_bgp_dump from CAIDA (and run "'sh ip bgp' format RIBs" through it), or use http://www.bugged.org/download/misc/bgpparser.c (after tweaking the defines to extract the correct fields) and pass "MRT format RIBs" through it. CAIDA merges multipleorigins into a generic entry, whereas bgpparser creates multiple entries. Either way you want a file with a.b.c.d/e AS ... a.b.c.d/e AS Then use something like Net::Patricia to lookup the AS for an IP address. The only slow thing seems to be reading in the file into memory (I guess you could daemonise it, or use a more parse efficient storage format it this matters). There is some scripts from a while back at http://kaizo.us/girona/bgp/ bgpparse.tar is the relevant bits out of CAIDA's larger package. aslookup.pl is very simple perl script route-table is a parsed version of the data from routeviews from June. Hope this helps John JANET-CERT ------------------------------------------- From: joe@oregon.uoregon.edu Because a number of people have expressed an interest in an IP->ASN DNS zone, if you're interested, the Routeviews project now has a test/static asn zone up that you can try, e.g.: % dig @archive.routeviews.org 13.142.223.128.asn.routeviews.org txt [snip] ;; ANSWER SECTION: 13.142.223.128.asn.routeviews.org. 86400 IN TXT "3582" [snip] % dig @archive.routeviews.org 109.131.229.169.asn.routeviews.org txt [snip] ;; ANSWER SECTION: 109.131.229.169.asn.routeviews.org. 86400 IN TXT "25" [snip] That was the original format. It now works as follows: % host -t txt 35.32.223.128.asn.routeviews.org 35.32.223.128.asn.routeviews.org text "3582" "128.223.0.0" "16" In addition to being able to get the stub ASN, a second zone will also let you get the AS path associated with a specific dotted quad. For example: % host -t txt 122.3.15.66.aspath.routeviews.org 122.3.15.66.aspath.routeviews.org text "2497 3356 1 189" "66.15.3.0" "24" 122.3.15.66.aspath.routeviews.org text "2497 3356 1" "66.15.0.0" "17" In parsing what's returned, be sure to plan to accomodate the possibility that you may get multiple records returned for a single query. Thanks, Joe St Sauver (joe@oregon.uoregon.edu) University of Oregon Computing Center ----------------------------------------------- From: gillsr@yahoo.com www.qorbit.net/code/ip2asn-v1.1.tar.gz ip2asn-coral.pl - very fast, uses Caida's Coral Reef package, requires route table dump. Initial load takes a bit to read route-file. ip2asn-server.pl - slower, requires a route-server, preferably one that supports 'show ip bgp $ip/32 shorter' syntax. --------------------------------------------- Can the RIPE NCC TTM group explain why such a service is needed when there are other packages available that do similar things? Slide #2 seems to state that you want a traceroute that includes the ASN. Slide #14 states "RIPE-NCC will set up an IP-AS mapping service with something like "traceroute -A". How will this be different than a standard traceroute from any Cisco router: TAU-gp1#trace www.cisco.com Translating "www.cisco.com"...domain server (128.139.6.1) [OK] Type escape sequence to abort. Tracing the route to www.cisco.com (198.133.219.25) 1 iucc.il1.il.geant.net (62.40.103.225) [AS 20965] 0 msec 0 msec 0 msec 2 il.nl1.nl.geant.net (62.40.96.117) [AS 20965] 68 msec 64 msec 68 msec 3 nl.de1.de.geant.net (62.40.96.101) [AS 20965] 72 msec 72 msec 72 msec 4 so-7-0-0.ar2.FRA2.gblx.net (208.48.23.145) [AS 3549] 72 msec 72 msec 72 msec 5 pos5-0-2488M.cr2.FRA2.gblx.net (67.17.65.53) [AS 3549] 72 msec 72 msec 72 msec 6 so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38) [AS 3549] 84 msec 80 msec 80 msec 7 so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30) [AS 3549] 88 msec 84 msec 80 msec 8 sl-bb21-lon-1-3.sprintlink.net (213.206.131.25) [AS 1239] 88 msec 88 msec 88 msec 9 sl-bb21-tuk-10-0.sprintlink.net (144.232.19.69) [AS 1239] 164 msec 164 msec 164 msec 10 sl-bb20-tuk-15-0.sprintlink.net (144.232.20.132) [AS 1239] 164 msec 164 msec 168 msec 11 sl-bb21-rly-15-1.sprintlink.net (144.232.20.120) [AS 1239] 168 msec 172 msec 164 msec 12 sl-bb23-rly-11-0.sprintlink.net (144.232.14.134) [AS 1239] 164 msec 176 msec 168 msec 13 sl-bb20-rly-9-0.sprintlink.net (144.232.14.117) [AS 1239] 176 msec 168 msec 172 msec 14 sl-bb25-sj-5-3.sprintlink.net (144.232.20.57) [AS 1239] 296 msec 228 msec 228 msec 15 sl-gw11-sj-10-0.sprintlink.net (144.232.3.134) [AS 1239] 232 msec 228 msec 232 msec 16 sl-ciscopsn2-11-0-0.sprintlink.net (144.228.44.14) [AS 1239] 220 msec 220 msec 224 msec 17 sjce-dirty-gw1.cisco.com (128.107.239.89) [AS 109] 228 msec 224 msec 224 msec 18 sjck-sdf-ciod-gw2.cisco.com (128.107.239.102) [AS 109] 228 msec 228 msec 228 msec 19 * www.cisco.com (198.133.219.25) [AS 109] 236 msec * Thanks, Hank
Dear Hank, On Wed, 10 Sep 2003, Hank Nussbacher wrote:
Can the RIPE NCC TTM group explain why such a service is needed when there are other packages available that do similar things?
From your previous postings, I have understood that you do not like the current model where every WG can ask the RIPE NCC for specific actions. However, this was the procedure at the time. Even with the advent of the NCC-services WG it appears to us as the correct procedure for something
Short summary. ============== Ip2asn is built as an internal tool in response to requirements raised inside the TTM WG. It is used to put ASN information into TTM products. Making this mapping function available externally is not much work at all. We know of no similar service that meets this particular need. Long version: ============= For starters, I disagree with the statement that this is a new service that was not approved by anybody beforehand. The TT-WG was set up for various reasons. One of them was to provide a forum where (paying) customers of the TTM service can learn about the development plans for the project and provide feedback. The issue of IP-AS mappings has been discussed several times in the last years, our plans have been presented at previous meetings, and the presentation that you are referring to, was in fact the outcome of a specific question raised in the WG. For those who haven't followed the TT-WG, let me briefly summarize what happened in the past: Since the start of the service, TTM has provided the IP-level path that a packet takes when traveling from source to destination based on traceroute-like probes. One frequently see changes in these paths. These changes can be caused by many things, but amongst the most common are: 1. Traffic is routed through different routers of the same upstream provider. (For example, when load balancing schemes are in use). 2. Traffic is routed through a different upstream provider. In order to quickly distinguish between #1 and #2, one can look at which AS the IP-addresses in the path belong to. This requires a mapping of IP-addresses to AS-numbers, at the time that the IP-trace was taken (as IP blocks may move from one AS to another over time). Sometime in 2002, we therefor added a column in the output showing the AS that every IP address belonged to. This mapping was based on whois queries. When this was presented to the TT-WG, the (valid) question was raised how accurate this mapping was and if it wouldn't be better to use a routing-table based approach. As we, nor anybody in the audience, knew the answer, we (the RIPE NCC TTM-group) agreed with the TT-WG to study this. The talk you are referring to is the direct result of this question. like this, because it is germane to the TT-WG and does not involve a significant amount of resources. Anyway, the conclusion from this study was that the IRR only produces the correct mapping in about 80%, switching to an approach based on routing tables (i.e. the RIS) increases that percentage to about 99%. Obviously, the more accurate the results, the more useful the output, and the conclusion looked simple: the TTM service should switch to a routing table based approach for IP to AS mappings. Implementation ============== Besides being accurate, the implementation also has to be fast, as we have to process 4000 to 5000 different IP addresses in a relatively short time. We also believe that we should use routing tables that we are already collecting for the RIS, this in order to ensure that data from one RIPE NCC service (TTM) is consistent with another. This will also give a performance boost, as all data resides on 1 local network. The best way to accomplish this, appears to be a daemon that loads all information into memory. serves queries and refreshes itself at regular intervals. Other tools =========== We were fully aware that other tools existed to do this job, but we believe that none of them meets our requirements. For the ones that you list: 0) Both NANOG traceroute and lft have a -A switch but get the prefix data from a routing registry (whois.ra.net) which has been shown to be incomplete, out of date, not maintained 1) http://www.cymru.com/Tools/getorgasn2.pl Relies on access to a router. comments: one router does not necessarily see all prefixes and origins one needs to combine data collected from various vantage points (RIS collectors, route-view peers) performance: each lookup is done with a 'sh ip bgp $prefix' command on the router, won't scale to thousands of lookups (or hurt router performance) 2) Net::Patricia Create ASCII prefix/AS table from a source of routing information (route-views quoted), use Net::Patricia to lookup. Comments: the idea is good, but the ASCII data and perl make it too slow. An ip2asn server at RIPE NCC could parse the data from RIS, keep everything in memory and refresh info daily. 3) "Routeviews project now has a test/static asn zone up that you can try" % dig @archive.routeviews.org 13.142.223.128.asn.routeviews.org txt comments: interesting idea but at the time it was still under development. strange replies on non-matched IPs, e.g. try host -t txt 7.227.290.195.asn.routeviews.org This could be a solution for traceroute, but in TTM we skip time consuming dns lookups on the testboxes and do offline processing; performing thousands of dns lookups for ip2as there will likely take too long too. 4) ip2asn scripts from Stephen Gill - starting from BGP table dump - contacting route server comments: BGP table dump covered above (good start, but not complete and ASCII is slow), route server is slow, won't scale to thousands of queries Why make this a service? ======================== Mapping IP to AS can be used in many tools, both that are published in the public domain as in tools used inside LIR's only. All these tools will benefit from more accurate data. To use a routing based IP-AS mapping for TTM, we need to develop and maintain some amount of code. Adding an interface to access the same data from the outside, requires very little additional work. In fact, I think that we'd be doing the community a dis-service if we would not make this tool available to everybody. Henk (with the help of Rene, Daniel and the rest of the TTM group) ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)
Henk Uijterwaal (RIPE-NCC) wrote:
Why make this a service? ========================
Mapping IP to AS can be used in many tools, both that are published in the public domain as in tools used inside LIR's only. All these tools will benefit from more accurate data.
To use a routing based IP-AS mapping for TTM, we need to develop and maintain some amount of code. Adding an interface to access the same data from the outside, requires very little additional work. In fact, I think that we'd be doing the community a dis-service if we would not make this tool available to everybody.
I *assume* that the development of this service will be funded 100% by the paying customers of the TTM and that any benefit that RIPE members will gain will be as a pleasant and cost-free side effect ? If not, why not ? Peter
At 11:14 AM 25-09-03 +0200, Henk Uijterwaal (RIPE-NCC) wrote:
For starters, I disagree with the statement that this is a new service that was not approved by anybody beforehand. The TT-WG was set up for
Huh? I made that statement? I said "Another new service I'd like to discuss is the TTM ip2asn service as presented at RIPE-46: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tracero..." I think you are reading things that are not quite there.
From your previous postings, I have understood that you do not like the current model where every WG can ask the RIPE NCC for specific actions. However, this was the procedure at the time. Even with the advent of the NCC-services WG it appears to us as the correct procedure for something like this, because it is germane to the TT-WG and does not involve a significant amount of resources.
From: http://www.ripe.net/ripe/wg/ncc-services/index.html#charter The aim of this WG would be to discuss at least the following: · performance of existing services · introduction of new services, new tools · an ongoing evaluation of the RIPE NCC Activity Plan Is it the RIPE NCC's view that this charter is no longer valid and the text for bullet #2 should instead be "introduction of new services, new tools that involve a significant amount of resources"?
------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------
That problem that we weren't having yesterday, is it better? (Big ISP NOC)
-Hank
Continuing in my previous view of examining RIPE services and alternatives that are available: At the RIPE meeting, I saw http://dnsmon.ripe.net. How is this different than: http://www.caida.org/cgi-bin/dns_perf/main.pl and http://www.cymru.com/DNS/dns.html Wouldn't it make sense to use these services to monitor country roots rather than create yet another new RIPE service? -Hank
On Fri, Sep 05, 2003 at 10:09:54AM +0200, Hank Nussbacher wrote:
Continuing in my previous view of examining RIPE services and alternatives that are available:
At the RIPE meeting, I saw http://dnsmon.ripe.net.
How is this different than: http://www.caida.org/cgi-bin/dns_perf/main.pl and http://www.cymru.com/DNS/dns.html
Wouldn't it make sense to use these services to monitor country roots rather than create yet another new RIPE service?
-Hank
If I have a quick look, and in my feeling the stats are quite different. First of all, RIPE NCC, as the operator of k.root-servers.net need some stats for there operations so why not make them public. Secondly the data is quite usefull, and once the infrastructure is in place it makes sense to use it for other nameservercomplexes as well. Regards, Andre Koopal MCI
On 05.09 10:09, Hank Nussbacher wrote:
Continuing in my previous view of examining RIPE services and alternatives that are available:
At the RIPE meeting, I saw http://dnsmon.ripe.net.
How is this different than: http://www.caida.org/cgi-bin/dns_perf/main.pl and http://www.cymru.com/DNS/dns.html
Wouldn't it make sense to use these services to monitor country roots rather than create yet another new RIPE service?
Hank, work on this started when we needed real data about the service quality of k.root-servers.net as seen from the users, e.g. from *a lot of* places. This was done as part of the RIPE NCC's responsibility to operate that server. Once we did it for one server the incremental work to do it for the other root servers as well was very small. We wanted to compare our service levels ;-). This was intended for the use by the k.root-servers.net operators, and other root name server operators. But why should we keep this data to ourselves? So we published it as alpha. Soon lots of people found it cool and suggested to monitor TLDs as well and again the additional effort involved was not very high. I immediately thought that it would very fair if tose responsible for the ccTLDs would contribute to the operating costs once this becomes a service. It turns out that a number of the European ccTLDs were not only prepared to pay a fair share but eager. So I expect that this will happen. This also sparked and influenced my thinking about measurements in general which I wrote up in ripe-271. This memo also explains why I think the RIPE NCC should do measurement and data collection activities, so I will not repeat it here. Henk might expand with more details. Daniel
Hoi Hank, On Fri, Sep 05, 2003 at 10:09:54AM +0200, Hank Nussbacher wrote: | Continuing in my previous view of examining RIPE services and alternatives | that are available: | | At the RIPE meeting, I saw http://dnsmon.ripe.net. I heard that the idea is not novell but comes originally from Caida who were seeking a broader measurement platform. | How is this different than: | http://www.caida.org/cgi-bin/dns_perf/main.pl is not a very widespread platform (4 probes?) | and | http://www.cymru.com/DNS/dns.html idem, and has a high smiley count. Actually I think the NCC should keep on running this and other services, because I have an explicit need to keep track of several large scale operational matters and we have an established trust and feedback mechanism in place from me (a LIR, RIPE member and TTM customer) to the folks at the NCC, eg it is a company that I fully trust to do these measurements in a proper manner. (I do not know anybody at Caida) -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
Continuing in my previous view of examining RIPE services and alternatives that are available:
At the RIPE meeting, I saw http://dnsmon.ripe.net.
How is this different than: http://www.caida.org/cgi-bin/dns_perf/main.pl and http://www.cymru.com/DNS/dns.html
Wouldn't it make sense to use these services to monitor country roots rather than create yet another new RIPE service?
at some ripe meeting or another, i presented a bit of research. in that research, we conducted an experiment using some "BGP Beacons." within weeks, ripe/ncc had set up a bunch of these beacons, in a fashion that was not usable for our experiments and with no clear goal other than <aol>ME TOO</AOL>. to my knowledge, no researcher has used them to date. all i could figure out was "if we hear of it, we must do it too." randy
Randy Bush wrote:
at some ripe meeting or another, i presented a bit of research. in that research, we conducted an experiment using some "BGP Beacons." within weeks, ripe/ncc had set up a bunch of these beacons, in a fashion that was not usable for our experiments and with no clear goal other than <aol>ME TOO</AOL>. to my knowledge, no researcher has used them to date. all i could figure out was "if we hear of it, we must do it too."
... another handy thing to use some of that surplus budget and staff on again. What has DNSMON got to do with assignment of IP & ASes ? Peter
Randy,
at some ripe meeting or another, i presented a bit of research. in that research, we conducted an experiment using some "BGP Beacons." within weeks, ripe/ncc had set up a bunch of these beacons,
You were one of the people asking for this, quoting from the minutes of the Rhodos meeting: <quote> Minutes Routing WG at RIPE43 [...] C. Route Flap Damping: Harmful? (Randy Bush) [...] Route flap damping parameters may have to be revised, but more data are needed; Randy asks for help, need more BGP beacons installed. </quote>
in a fashion that was not usable for our experiments
There are, at the moment, 5 beacons (or sets of beacons) worldwide. All 5 are set up slightly differently, and thus show different behavior, that may or may not make them suitable for your specific experiment. And in the paper you submitted to IMW2003, you even question yourself whether the NCC beacon data is suitable for your studies or not. Then, our beacon setup has been published but is in no way cast in stone. If you want us to make chances, tell us WHAT you want changed. In fact, this is already about to happen, we are currently discussing changes in the beacon pattern with one of the co-authors of the 2 papers mentioned above, including a pattern that can only be done with the RIS.
and with no clear goal other than <aol>ME TOO</AOL>.
Besides responding to the question raised by you, we spoke to several BGP experts afterwards, and all seemed to agree that this was a good idea, so we did it. And before anybody complains that all this cost money, the beacons come essentially for free with the RIS infrastructure, setting them up was half an afternoon of work for 1 engineer, maintaining them is a matter of minutes per week.
to my knowledge, no researcher has used them to date.
You are wrong here, 1 thesis has been published about the data http://www.net.informatik.tu-muenchen.de/~sara/thesis/ and I know for a fact that 2 papers to be submitted to refereed conferences are in the works. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)
At 09:11 PM 05-09-03 +0200, Henk Uijterwaal (RIPE-NCC) wrote:
Besides responding to the question raised by you, we spoke to several BGP experts afterwards, and all seemed to agree that this was a good idea, so we did it.
And before anybody complains that all this cost money, the beacons come essentially for free with the RIS infrastructure, setting them up was half an afternoon of work for 1 engineer, maintaining them is a matter of minutes per week.
The dnsmon service might we wonderful and better than anything out there and I may even end up using it. My point is that now that there is an ncc-services list, that the RIPE NCC, whenever a new service is decided upon, that a message be sent to the ncc-services list, giving a short description of the service, the rationale for setting it up, and the estimated budget and manpower needed to run the service. This will save us all from having to monitor the 20 or so WG lists for new services being planned and then finding out about it when it is too late.
Henk
-Hank
At 06/09/2003 22:08 +0200, Hank Nussbacher wrote:
My point is that now that there is an ncc-services list, that the RIPE NCC, whenever a new service is decided upon, that a message be sent to the ncc-services list, giving a short description of the service, the rationale for setting it up, and the estimated budget and manpower needed to run the service.
Hank, all, this is certainly something that I agree with. And have said so earlier. Axel
On måndag, sep 8, 2003, at 07:49 Europe/Stockholm, Axel Pawlik wrote:
At 06/09/2003 22:08 +0200, Hank Nussbacher wrote:
My point is that now that there is an ncc-services list, that the RIPE NCC, whenever a new service is decided upon, that a message be sent to the ncc-services list, giving a short description of the service, the rationale for setting it up, and the estimated budget and manpower needed to run the service.
Hank, all,
this is certainly something that I agree with. And have said so earlier.
This is to my knowledge one of the intents of the working group. As was also said in Amsterdam by both me and Axel. I took away two things from the WG meetings 1) We need to go through the activity plan in detail. At least then we might get the people awake to know about it - and _then_ we can have useful discussions (nothing intended to the people that _did_ talk. You where just very few....). 2) We need a more detailed financial walk-through matching the activity plan. I talked briefly to Axel in the hallway afterwards and he seemed positive to this. Best regards, - kurtis -
On 05.09 21:11, Henk Uijterwaal (RIPE-NCC) wrote:
... and I know for a fact that 2 papers to be submitted to refereed conferences are in the works.
.... not to mention operational uses such as my study of anycasting behavior before we deployed the first anycast instance of K; something only possible with both the RIS and customised beacons. Me too ;-) Daniel
participants (11)
-
Andre Koopal -
Axel Pawlik -
Daniel Karrenberg -
Hank Nussbacher -
Hans Petter Holen -
Henk Uijterwaal (RIPE-NCC) -
Kurt Erik Lindqvist -
Peter Galbavy -
Pim van Pelt -
Randy Bush -
Stephen Gill