- Test - lists.nanog.org

Mailing list for discussion of Internet technical issues
by Greg Harp 21 Nov '98

21 Nov '98

Is there a mailing list where folks can discuss actual Internet networking and routing issues? Is there one where I can watch for reports of various major outages or SNAFUs on the 'net? Is there one where I may be able to get in contact with various powers that be around the 'net to discuss how we may all work together to stabilize and improve service for our customers? Darn, I thought this was that mailing list... Recommended reading for all those continuing to discuss the legal issues of SPAM and the RBL as well as the fallout from those discussions which seems to have deteriorated to adolescent playground bickering: http://www.nanog.org/NANOG.charter.html http://www.nanog.org/aup.html Please take this discussion elsewhere, folks!!!! -- Greg Harp Manager - Internet Network Engineering SBC Internet Services, Inc. 972 470-1207 gharp(a)swbell.net

3 2

Re: AS_PATH length and route selection (WAS: Strange BGP announcement)
by Sean M. Doran 21 Nov '98

21 Nov '98

I Am Not An Isp <patrick(a)ianai.net> writes: [wrt RFC 1771, A Border Gateway Protocol 4] > There are just other parts of the RFC with which I'm > not so sure I agree. Oh do tell. Better still, tell the IDR WG. There are open drafts which might be apropos to your concerns, and certainly nobody would assert that they are flawless. Sean.

1 0

Re: NSI policy on lame delagations
by Dean Anderson 21 Nov '98

21 Nov '98

I think the technique is called 'lazy evaluation' ;-) --Dean At 08:18 PM 11/20/1998 -0500, Daniel Senie wrote: >Patrick Greenwell wrote: >> >> Seems that NSI has a new policy on lame delagations. I never heard >> anything about this. Anyone else? > >Interesting. Their policies state you must have the name servers for a >domain up and running before you apply for a domain, but they clearly do >not enforce that... Sounds like they're adding checking after the fact. >It still would be nice if they queried the name servers you told them >were to be used during the application process, though. > >Dan > >-- >----------------------------------------------------------------- >Daniel Senie dts(a)senie.com >Amaranth Networks Inc. http://www.amaranthnetworks.com > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

RE: Digital Bill of Rights
by Bob Allisat 20 Nov '98

20 Nov '98

James, I feel it is important to reply to your reasoned article with an equal response. Mr. Fowler wrote: > [Fowler, James] Bob, Yes you do have the right to e-mail > anyone you want. I can refuse e-mail from anyone I want. This is > the same for the US postal service. If I choose not to accept > e-mail from you, then you don't get a real say in the matter. The > RBL is a voluntary list. i.e. your network is used for Spam, one > can not get off of your Spam list, they document what they have > done, then add your address to the RBL. it is punishment for you > not respecting the rights and requests of others not to send Spam, > so we (RBL Users) have a right not to accept Spam. This is NOT > envelope steaming, this is looking at the address from who it was > sent from and then stopping the e-mail from going further. > > It is MY company's network, My company's storage system, > My company's connection, My company's money paid for all of this. > My company CAN choose who we want to use our services. > > Your attitude, "Welcome to the digital age. Here is 2000 > pieces of Spam for you. Thanks for the use of your bandwidth and > storage." This is not right. It would be like someone going to > your house, walking in, going to you fridge, getting a drink, and > using your phone and watching your TV, without your permission. > Is this what you really want? This list is a group of people who > have wasted too many hours in trying to get people like you to > listen and please stop the spamming, but it takes a discussion / > Flame mail to do this. Why? Mail is mail is mail in my opinion. And what you do on a *private* server is your own business. Once that server opens for general public usage the obligation is to simply deliver the god-damned mail. Not snif or steam or read the addresses to see if they are kosher. We have our rights and freedoms in a civil society. One day they will be integrated into our laws and various constitutions. Until then I guess Public ISPs will continue to get away with abuses. In my opinion all this RBL nonsense is vastly more destructive in the long term than a few ad e-mails. You may agree to disagree. That too is your right. However you still may not block, manipulate or deny any mail directed at me. *UNLESS* I explicitly give you that permission. Otherwise - buzz of boys. You're treading on dangerous ground. Bob Allisat Free Community Network _ bob(a)fcn.net . http://fcn.net http://fcn.net/allisat _ http://fcn.net/draft

4 3

RE: recent rash of otherlistcontent posts
by Dean Anderson 20 Nov '98

20 Nov '98

I'm usually easily sucked into these political discussions, and even I'm staying out of this one. Everything has been discussed already last winter or last fall. Nothing new has been added. Please read the Nanog Archives and make sure you have something new and worthwhile before posting more on this topic. Especially you oldsters, who know this has been hashed over before. Point people to the archives instead of re-typing. --Dean anti-spammers-are-worse-than-spam Anderson. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Digital Bill of Rights
by Andrew Staples 20 Nov '98

20 Nov '98

Please, everyone, follow the good advice posted earlier. Actually, it's almost as good as BOFH. Andrew -----Original Message----- From: gstewart(a)river.netrover.com <gstewart(a)river.netrover.com> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Thursday, November 19, 1998 4:35 PM Subject: The RBL & Bob. >Wait... Before adding to this thread, please check out the following... > >http://www.netizen.org/Howling/Kooks/Allisat/ > >... just something I found on a search engine ;) >

1 0

Re: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts
by Adam D. McKenna 20 Nov '98

20 Nov '98

I don't know about NetBSD, but Linux has a kernel option "IP: Always Defragment", when setting up your box for routing or filtering. The main reason one would do this would be to prevent hosts inside their firewall from being attacked with the various IP-fragment DoS attacks against MS Windows machines. --Adam --- bash: syntax error near unexpected token `:)' Adam D. McKenna adam(a)flounder.net -----Original Message----- From: Greg A. Woods <woods(a)most.weird.com> To: North America Network Operators Group <nanog(a)merit.edu>; NetBSD Networking Technical Discussion List <tech-net(a)NetBSD.ORG> Cc: Mark Kosters <markk(a)internic.net> Date: Friday, November 20, 1998 5:03 PM Subject: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts ::[[ NOTE: this message is cross-posted to NANOG and tech-net, as well as ::Cc'ed to Mark Kosters (because I don't know if Mark reads either list). ::Please reply either directly to me, or to *one* of those lists as ::appropriate (it's probably not relevant to discuss on NANOG now that the ::problem has been identified unless it's a problem with some particular ::piece of equipment, in which case it would be good to identify it so ::others can fix similar problems. ]] :: ::I've discovered the cause of those problems with TCP connections to/from ::some InterNIC.net hosts (and some other hosts, one of which was trying ::to send me e-mail and thus necessitated that I debug it in more detail). :: ::Now that I know the cause I can say that this problem is usually ::indicative of a firewall with a non-compliant TCP/IP implementation, ::though it may also indicate an unwise firewall filtering policy too. :: ::The problem has to do with the failure of a host to fragment larger ::packets on demand (i.e. when the other host sends an ICMP "needs frag" ::notification). This may be because the ICMP packet never gets through ::(perhaps someone who didn't understand TCP/IP and ICMP and everything ::else related implemented a filter on all "abnormal" ICMP packets); or it ::may be because the receiving host doesn't understand the ICMP "needs ::frag" request (and also doesn't implement path MTU discovery, or have I ::got that backwards?). :: ::No matter what the problem really is, I'm sure a *lot* of people would ::be much happier if this problem were fixed, specifically for the WHOIS ::service (though I've also had troubles receiving HTTP too). I got quite ::a few replies about similar experiences when I first posted about this ::on NANOG recently. :: ::Here's a sample trace collected from the PPP router upstream which shows ::the outgoing ICMP packets and the incoming TCP retransmissions, ::un-fragmented, even after the first request to fragment: :: ::15:02:56.097980 204.92.254.2.4721 > 198.41.0.6.43: S :1660910424:1660910424(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp :5148233 0> (ttl 62, id 25948) ::15:02:56.420273 198.41.0.6.43 > 204.92.254.2.4721: S :1062510833:1062510833(0) ack 1660910425 win 8760 <mss 1460> (DF) (ttl 245, :id 4189) ::15:02:56.674783 204.92.254.2.4721 > 198.41.0.6.43: . ack 1 win 17520 (ttl :62, id 25951) ::15:02:56.677143 204.92.254.2.4721 > 198.41.0.6.43: P 1:6(5) ack 1 win 17520 :(ttl 62, id 25952) ::15:02:57.175854 198.41.0.6.43 > 204.92.254.2.4721: . ack 6 win 8760 (DF) :(ttl 245, id 4190) ::15:02:59.393169 198.41.0.6.43 > 204.92.254.2.4721: P 1:4(3) ack 6 win 8760 :(DF) (ttl 245, id 4191) ::15:02:59.532326 204.92.254.2.4721 > 198.41.0.6.43: . ack 4 win 17517 (ttl :62, id 25994) ::15:03:00.326761 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 4192) ::15:03:00.327688 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19390) ::15:03:00.420416 198.41.0.6.43 > 204.92.254.2.4721: . 1464:2914(1450) ack 6 :win 8760 (DF) (ttl 245, id 4193) ::15:03:00.421157 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19391) ::15:03:03.381245 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 4194) ::15:03:03.382120 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19392) ::15:03:10.619116 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 4195) ::15:03:10.620110 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19411) ::15:03:24.974732 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 4196) ::15:03:24.975626 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19413) ::15:03:53.941690 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 4197) ::15:03:53.942656 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19418) ::15:04:50.256764 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 52333) ::15:04:50.257959 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19425) ::15:05:46.509834 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win :8760 (DF) (ttl 245, id 43047) ::15:05:46.510716 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 :unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19433) ::15:06:29.615496 198.41.0.6.43 > 204.92.254.2.4721: R 4:4(0) ack 6 win 0 :(ttl 55, id 23874) :: ::Note that ICMP packets get through correctly, seemingly because NetBSD ::fragments them on the way through (I suppose a "needs frag" packet could ::be sent in this case too, but that does seem a little too intertwined to ::be reliable). :: ::Here's the trace of two big (-s 1400) packet pings from the router's POV: :: ::15:17:21.092624 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 253, id :41845) ::15:17:21.366494 198.41.0.6 > 204.92.254.2: icmp: echo reply (ttl 246, id :25176) ::15:17:21.978679 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 253, id :41855) ::15:17:22.227824 198.41.0.6 > 204.92.254.2: icmp: echo reply (ttl 246, id :25351) :: ::And here's what I see on my end of the link corresponding to the above: :: ::15:17:17.466591 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 255, id :41845) ::15:17:18.467986 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 255, id :41855) ::15:17:18.487006 198.41.0.6 > 204.92.254.2: icmp: echo reply (frag :25176:984@0+) (ttl 244) ::15:17:18.489940 198.41.0.6 > 204.92.254.2: (frag 25176:24@984) (ttl 244) ::15:17:19.251136 198.41.0.6 > 204.92.254.2: icmp: echo reply (frag :25351:984@0+) (ttl 244) ::15:17:19.263880 198.41.0.6 > 204.92.254.2: (frag 25351:24@984) (ttl 244) :: ::Perhaps routers (i.e. NetBSD when it's routing, in this case) should ::also fragment TCP packets on the way through if there are "too many" ::retransmissions of over-sized packets (one's too many for me, but I ::guess on high-latency links there might be two or three in the pipe -- ::perhaps a timer would help adjust when to do local fragmenting). :: ::-- :: Greg A. Woods :: ::+1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> ::Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com> :: : :

1 0

rbl-discuss@puck.nether.net
by Jared Mauch 20 Nov '98

20 Nov '98

new mailing list out there. rbl-discuss(a)puck.nether.net for discussion of rbl type filtering, consequences, etc. to get on: send mail to rbl-discuss-request(a)puck.nether.net subject: subscribe to get off: (insert pun here) send mail to rbl-discuss-request(a)puck.nether.net subject: unsubscribe -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/

1 0

Re: Digital Bill of Rights
by Jeff Mcadams 20 Nov '98

20 Nov '98

Thus spake Bob Allisat > There is absolutely no reason for > ISPs to do *anything*. Except for > implementing a USER CONFIGURABLE > INTERFACE that allows personal > filtering of E-Mail *before* it > is downloaded. I called this the > ALLISAT INDEX once upon a time > but what is a name? Well...Bob, while I think you're a raving lunatic...guess what? You can do this with the RBL as it stands! At least our MTA allowed us to set it up this way...It's not something that can be decided on the fly when a specific piece of email is retrieved (say through Eudora), but its a setting that our users set on whether to use RBL or not. Isn't that a radical idea...that ISP's can implement things how they want because its their equipment. Now, please...take your raving lunacies. We can't help it if you can't figure out how to configure your MTA like you wish. (My apologies if this is more noise than signal...I can't believe I'm actually responding to Bob...sheesh...hopefully its at least *somewhat* operationally related since it involves MTA config) For what its worth...our MTA (exim in our shop) allows us to set an RBL warning on messages globally, but not block them on a system-wide level. This then let's our users configure procmail, filter, or even an exim filter to dump any messages which have the RBL warning on them. Incidentally, we have a system level service the users can "sign up" for (its set up in our billing system as a seperate account type, but its free) that will accomplish this basically at the system level...but again, its user specific. -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

1 0

RE: Digital Bill of Rights
by owen＠dixon.DeLong.SJ.CA.US 20 Nov '98

20 Nov '98

Bob, Buy a clue. Noone can blackhole mail directed at you unless it is traversing their server. Given the nature of SMTP, this should mean that the host falls into one of the following categories: A machine owned by the Sender. A machine owned by someone the Sender has a transit agreement with. A machine owned by someone you have a transit agreement with. A machine owned by you. Of course, in reality, there is an additional category which you seem to be saying should be forced to carry said traffic, but which in fact should not: A machine not owned by you, the sender, or anyone you have a transit agreement with, from which you or the sender are attempting to steal service for the purpose of mail relay. The internet is not a federally funded or government enterprise, and is not a regulated monopoly. As such, there is no universal service requirement. Any person who owns a computer or pays for a network link has the right to choose how that network link is used. If they choose to allow Paul Vixie and his group to assist them in determining sources from which they don't want to receive traffic, that is the prerogative of the person paying for the equipment. I don't have a right to prevent the USPS from delivering you mail. However, if I opened a shipping company, I would have the right to refuse to accept packages with your address as a destination, and I would certainly have the right to refuse to accept packages from you. If a group of shipping companies agreed to subscribe to a service allowing them to share the names/addresses of abusive customers, then that would be kosher too. Noone is treading on your rights, and what Paul is doing is not the act of a vigilante. Paul has not forced anyone to subscribe to his service. Paul could charge for this service. The fact that he chooses to provide this service for free (at significant personal expense, I might add) is testament to his community-mindedness. A vigilante is someone who takes the law into their own hands without consent of the effected parties. Paul is merely providing a service which people can subscribe to which allows those people to choose who they provide or do not provide service to. The choices are based on well documented and published criteria. It is much easier to get off the RBL than to get on. Paul and his team are, in my experience, usually very thorough in their investigations prior to adding a spammer to the RBL, and they tend to target as specifically as possible the smallest number of hosts which will stop the problem. If you don't like what Paul is doing, you are welcome to not subscribe to his list and put the necessary infrastructure in place to assure that none of the systems in the last two categories is subscribed. Then, the only way anyone will block mail to you is if the sender is using machines that have chosen not to carry the senders traffic. Owen > In my opinion all this RBL nonsense is > vastly more destructive in the long > term than a few ad e-mails. You may > agree to disagree. That too is your > right. However you still may not block, > manipulate or deny any mail directed at > me. *UNLESS* I explicitly give you that > permission. Otherwise - buzz of boys. > You're treading on dangerous ground. > > Bob Allisat > > Free Community Network _ bob(a)fcn.net . http://fcn.net > http://fcn.net/allisat _ http://fcn.net/draft > >

1 0