June 2004 - Test - lists.nanog.org

Level 3 Issues?
by Cody Lerum 28 Jun '04

28 Jun '04

Depending on the Yahoo you get...66.218.71.198 traceroute to 66.218.71.198 (66.218.71.198), 30 hops max, 38 byte packets 1 ge-0-3-0-7-1q-4crn-bzn.mt.core.cutthroatcom.net (209.137.232.209) 0.398 ms 0.297 ms 0.315 ms 2 fe-0-0-0-rf-45m-silo-bzn.mt.core.cutthroatcom.net (209.137.235.194) 0.812 ms 0.750 ms 0.642 ms 3 fe-0-0-0-rf-45m-bxt-bzn.mt.core.cutthroatcom.net (209.137.235.202) 1.811 ms 1.593 ms 1.082 ms 4 t3-0-0-3-ta-hln.mt.core.cutthroatcom.net (209.137.235.218) 7.689 ms 6.538 ms 7.005 ms 5 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.444 ms 20.485 ms 18.041 ms 6 so1-1-0-2488M.ar1.SJC2.gblx.net (67.17.64.65) 44.443 ms 41.470 ms 37.794 ms 7 so-4-0-0.edge1.SanJose1.Level3.net (4.68.127.53) 41.383 ms 40.958 ms 41.587 ms 8 so-1-2-0.bbr1.SanJose1.Level3.net (209.244.3.137) 48.844 ms 46.521 ms 41.600 ms 9 ge-9-1.ipcolo3.SanJose1.Level3.net (64.159.2.73) 43.877 ms ge-10-1.ipcolo3.SanJose1.Level3.net (64.159.2.105) 43.767 ms 46.232 ms 10 unknown.Level3.net (64.152.69.30) 476.219 ms 476.244 ms 480.827 ms 11 * UNKNOWN-66-218-82-230.yahoo.com (66.218.82.230) 495.937 ms 12 * alteon4.68.scd.yahoo.com (66.218.68.13) 486.236 ms 495.863 ms Anyone else seeing this? >From www.dnsstuff.com as well Pinging 66.218.71.198 [66.218.71.198]: Ping #1: Got reply from 66.218.71.198 in 551ms [TTL=234] Ping #2: Got reply from 66.218.71.198 in 590ms [TTL=234] Ping #3: Got reply from 66.218.71.198 in 552ms [TTL=234] Ping #4: Got reply from 66.218.71.198 in 550ms [TTL=234] Done pinging 66.218.71.198! -C

1 0

The use of .0/.255 addresses.
by Jonathan McDowell 27 Jun '04

27 Jun '04

Have just spent some time trying to track down what seemed to be an elusive problem, I thought I'd mention it here. I've had problems accessing www.level3.net, www.ebay.co.uk and www.dabs.com (and a few others I don't recall). As I'm the first user of a reasonably new netblock I thought it might be something to do with filters on our upstreams or similar. Trying an IP from our older netblock worked without problems, which seemed to back this up. However eventually I tracked it down to the use of the .0 address from the new netblock; changing to use the .1 address meant I could access the above sites without any difficulty. Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them. J. -- /-\ | This is not a daffodil! This is |@/ Debian GNU/Linux Developer | not a daffodil! \- |

12 15

Re: The use of .0/.255 addresses.
by sthaug＠nethelp.no 27 Jun '04

27 Jun '04

> This is what happens when your educational system continues to teach > classful routing as anything other than a HISTORICAL FOOTNOTE > *coughCiscocough*. Yes, it sure would be nice if Cisco would revise some of their CCNA course material and exams. Plenty of classful stuff still left there, I'm afraid. It's kind of stupid when you have to tell fellow workers trying to get a certification "This isn't real life, you just have to learn it for the exam. In real life we use CIDR." Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: The use of .0/.255 addresses.
by Fergie (Paul Ferguson) 26 Jun '04

26 Jun '04

Amen, brother. - ferg -- Richard A Steenbergen <ras(a)e-gerbil.net> wrote: Do you part to help control the ignorant population: whenever you hear someone say "class [ABC]" in reference to anything other than a historical allocation, smack them. Hard. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

3 2

Teaching/developing troubleshooting skills
by Pete Kruckenberg 26 Jun '04

26 Jun '04

I'm working on trying to teach others in my group (usually less-experienced, but not always) how to improve their large-network troubleshooting skills (the techniques of isolating a problem, etc). It's been so long since I learned network troubleshooting techniques I can't remember how I learned them or even how I used to do it (so poorly). Does anyone have experience with developing a skills-improvement program on this topic? If you've tried such a thing, what worked/didn't work for you? Outside training? Books? Mentoring? Motivational posters? I'm particularly sensitive to the "I got my CCNA, therefore I know everything there is to know about troubleshooting" perspective, and how to encourage improving troubleshooting skills without making it insultingly basic. Thanks for your help. Pete.

5 4

RE: Unplugging spamming PCs
by Larry Pingree 25 Jun '04

25 Jun '04

Authentication and Authorization are two separate and distinct issues. TLS and Authentication have been around for quite a while, but without centralized authorization it will never be deployed by disparate corporations for inter-domain mail! This will not stop spam. Unless of course you want to manage user accounts or certificates with every single customer that you want to have conversations with. Authorization must still be authorized by a third party agency which verifies validity between everyone involved in communications. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, June 25, 2004 12:14 PM To: Larry Pingree Cc: jshen(a)spymac.com; nanog(a)merit.edu Subject: Re: Unplugging spamming PCs On Fri, 25 Jun 2004 09:11:36 PDT, Larry Pingree said: > > What I am proposing is have a registry that you must register > with before other mail servers will accept mail from you. Similar to how > MAPS RBL works, but the mail server itself, enforces it, rather than a > firewall or a ancillary device ACL. This could be made a standard of > SMTP. Yet another "it won't do any good till everybody deploys it". http://www.rhyolite.com/anti-spam/you-might-be.html

3 2

Question from NETCONF working group
by Rob Enns 25 Jun '04

25 Jun '04

Hi, The IETF's NETCONF WG is trying to select a retrieval filter mechanism for use with <get-config> and <get> operations. The fundamental issue is whether to use a subset of the XPath language or whether to define a mechanism based on XML subtree matching. Your comments can help us decide which propsal to choose. Here's the basic NETCONF <get> protocol operation exchange: <rpc message-id="101" xmlns="netconf-uri"> <get> <filter filter-type="filter-uri"> ... filter data ... </filter> </get> </rpc> <rpc-reply message-id="101" xmlns="netconf-uri"> <data> ... XML selected by the filter criteria ... </data> </rpc-reply> There are two options under consideration for the mandatory filter mechanism (i.e., standard values for the 'filter-type' attribute). If we can't get consensus on the mandatory to implement filter, then we will probably make both optional. A) XML sub-tree filtering A mechanism that allows exact match of element and attribute content, as well as the selection of specific subtrees. (This is implemented in Junoscript.) B) Xpath subset A small subset of the Xpath standard that provides essentially the same (or more) filtering functions as the subtree filter. (Note that full implementation of the Xpath 1.0 standard will be optional, and identified by the #xpath capability.) Operator and application programmer preference is really the deciding factor here. Approach (A) uses XML encoding that looks like the data model XML that will be returned in the response. Approach (B) uses an Xpath string encoding in the request, and the corresponding XML is returned in the response. Here are some example requests in both formats, followed by the response that would be returned in both cases. ------------------------------------------------------------------------ - E1) Select the entire <users> sub-tree Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree-uri"> <users xmlns="http://example.com/schema-1"/> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"/> t://users </filter> </data> </get> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> <user> <name>barney</name> <type>admin</type> <full-name>Barney Rubble</full-name> <company-info> <dept>2</dept> <id>3</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E2) Select all 'name' elements within the 'users' sub-tree Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree-uri"> <users xmlns="http://example.com/schema-1"> <user> <name/> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user/name </filter> </data> </get> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>root</name> </user> <user> <name>fred</name> </user> <user> <name>barney</name> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E3) One specific <user> entry Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="fred"] </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E4) Specific elements from a specific <user> entry Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type/> <full-name/> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="fred"]/name | t://users/user[name="fred"]/type | t://users/user[name="fred"]/full-name </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - C.7) Multiple sub-trees Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"/> <user> <name>root</name> <company-info/> </user> <user> <name>fred</name> <company-info> <id/> </company-info> </user> <user> <name>barney</name> <type>superuser</type> <company-info> <dept/> </company-info> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="root"]/company-info | t://users/user[name="fred"]/company-info/id | t://users/user[name="barney" and type="superuser"]/company-info </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"/> <user> <name>root</name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <company-info> <id>2</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - C.8) Table with attribute naming Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <t:interfaces xmlns:t="http://example.com/schema-2"/> <t:interface t:ifName="eth0"/> </t:interfaces> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-2"> t://interfaces/interface/[@ifName="eth0"] </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <t:interfaces xmlns:t="http://example.com/schema-2"> <t:interface t:ifName="eth0"> <t:ifInOctets>45621</t:ifInOctets> <t:ifOutOctets>774344</t:ifOutOctets> </t:interface> </t:interfaces> </data> </rpc-reply>

1 0

Can a customer take IP's with them?
by Alex Rubenstein 25 Jun '04

25 Jun '04

Should a customer be allowed to force a carrier to allow them to announce non-portable IP space as they see fit to any other carriers of their choosing when they are no longer buying service from the original carrier [that the space is assigned to]? According to ARIN regulations, the space does not "belong" to us but we have the right to assign or revoke the space to our customers as we see fit. In addition ARIN regulations specifically prohibit us from transferring or selling the IP space to another customer (even if we want to). NAC has a customer who is leaving NAC. As part of normal procedure (and also because the space provided to us by ARIN is non portable), the customer has been informed that the IP space used by the customer will not be available to be used by the customer subsequent to them leaving us. It should be mentioned that the following facts exist, and cannot be disputed: a) customer has obtained space directly from ARIN over a year ago, but has chosen not to renumber from space allocated from us. This was solely their choice, and we did not restrict this in any way. b) customer is exercising the right not to renew the business agreement, and is leaving NAC voluntarily. Thus, they are attempting to file for and obtain a temporary restraining order (TRO), and ask for the following: -- start -- "NAC shall permit CUSTOMER to continue utilization through any carrier or carriers of CUSTOMER's choice of any IP addresses that were utilized by, through or on behalf of CUSTOMER under the current agreement during the term thereof (the "Prior CUSTOMER Addresses") and shall not interfere in any way with the use of the Prior CUSTOMER Addresses, including, but not limited to: (i) by reassignment of IP address space to any customer; aggregation and/or BGP announcement modifications (ii) by directly or indirectly causing the occurrence of superseding or conflicting BGP Global Routing Table entries; filters and/or access lists, and/or (iii) by directly or indirectly causing reduced prioritization of access to and/or from the Prior CUSTOMER Addresses. NAC shall provide CUSTOMER with a LOA within 7 days of CUSTOMERS's written request for sale, NAC shall permit announcement of the Prior CUSTOMER Address to ANY carrier, IP transit, or IP peering network." -- end -- In other words, customer is asking a court to rule whether or not IP space should be portable, when an industry-supported organization (ARIN) has made policy that the space is in fact not portable. It can be further argued that the court could impose a TRO that would potentially negatively affect the operation of my network. NAC does not want to be forced to rely on a customer's ability to properly make complex routing updates that if done improperly could disrupt the entire NAC network. We believe there is a great danger to NAC that their routing mistakes could take down some or all of our network infrastructure. Another VERY important issue to bring up: If customer is granted the legal right to continue to use IP space that is registered to NAC by ARIN, NAC runs into the very serious problem of being liable for all of the Spam that could be generated by the customer and all of the RBLs that the carrier may be added to [that of course will effect all of NAC's customers] with no ability to revoke the IP space to protect itself. This has to potential to effect the NAC network in a catastrophic manner. I'd love any comments from anyone.

19 27

Re: Attn MCI/UUNet - Massive abuse from your network
by Jeff Shultz 25 Jun '04

25 Jun '04

** Reply to message from Brad Knowles <brad.knowles(a)skynet.be> on Fri, 25 Jun 2004 18:14:43 +0200 > At 8:44 AM -0700 2004-06-25, Jeff Shultz wrote: > > > At least if someone in this "clearing house" sells it to the > > terrorists, they will have had to work for it a bit, instead of having > > us hand it to them on a silver platter, as the FCC seems to want. > > Not true. If the information is forced to be completely in the > open, then everyone knows it's not insecure and no one depends on the > fact that it was supposed to be kept secret. This is a case where > you are more secure the more open the information is -- indeed, as we > are in most cases, which is why we have the age-old security mantra > of "security through obscurity is not secure". > Do you realize that the basic element of security, the password, is based on the entire premise you just dismissed? And yet we still use them - and depend on the fact that they are supposed to be kept secret. The problem with being totally open about infrastructure is that there are some vulnerabilities that simply cannot or will not be fixed - wires sometimes have to run across bridges, redundant pumping stations are too expensive... in these cases is it not better to hide where these vulnerabilities are? The problem with your point is that even if the information is forced to be completely in the open, that is no guarantee that it will be fixed, and people _do_ depend on this stuff, regardless of its reliability or security. Do you really think that if we publish all the insecurities of the Internet infrastructure that anyone is gonna stop using it, or business, government, and private citizens are going to quit depending on it? Security through obscurity is not secure - but sometimes it's all you have. -- Jeff Shultz A railfan pulls up to a RR crossing hoping that there will be a train.

4 3

RE: Unplugging spamming PCs
by Larry Pingree 25 Jun '04

25 Jun '04

What I am proposing is have a registry that you must register with before other mail servers will accept mail from you. Similar to how MAPS RBL works, but the mail server itself, enforces it, rather than a firewall or a ancillary device ACL. This could be made a standard of SMTP. LP Best Regards, Larry Larry Pingree 408-543-2190 "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Joe Shen [mailto:jshen@spymac.com] Sent: Thursday, June 24, 2004 6:36 PM To: Larry Pingree Cc: nanog(a)merit.edu Subject: RE: Unplugging spamming PCs Hi, >Mail servers should be registered just like domains and shutdown by a >registrar if they are misusing their registered services. This really >needs to be handled by a multi-lateral legal solution, industry will not >fix it alone. No, I don't think this is good solution First of all, we could not ask customers to register everything they planned with leased line without legal reasons. Second, if I hire DSL/leased_line service from ISP and set up domain name for myself, ISP could not ask me to tell them which port should be opened as I'm not taking a firewalling service, I'm not a member of my service provider. I should be able to do anything that are not perhibited by law or affact someothers. Blocking_port_25 indicates ISP pre-assume that customers will SPAM their network. But, SPAMmer is just a very small group of people. Maybe most of them comes from other countries ( what happens in China). To me, the proper way of anti-spam may ask cooperation between ISPs and Email service providers. Anyway, strengthening anti-spam ability in Email server is a must. regards Joe > >LP > >Best Regards, > >Larry Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com

3 3