- NANOG - lists.nanog.org

Re: Update on mail bombing threats--not so funny
by Vadim Antonov 11 Jan '97

11 Jan '97

-----BEGIN PGP SIGNED MESSAGE----- I told it many times already that the freedom of speech includes not only right to speak but also right not to listen. Internet is very good at the first part; and woefully indaequate at the second. Can it be fixed? Of course. But the first step in filtering out those who are trying to push their unwanted speech on us is to make sure they won't pretend to be somebody whose words we'd want to listen to. So -- the problem has two aspects: the first is authentication, the second is defense against flooding attacks. They are closely related, but not identical. The source address verification is powerful enough to get flood attacks stopped. It is still not enough to get rid of unwanted messages. The second line of defense should be digital signatures on messages, certified by some authorities (what is "authority" depends on your personal point of view -- you're free to choose whom to believe) which to a some extent make sure that signatures correspond to physical people. Then you can just stop accepting any unsigned mail (note that a reputable anonymous remailer would also check signatures on incoming messages; and substitute them with its own). There's no magic technology involved; this is just the problem of how to actually implement it. Until we do that we all live in danger of having our name smeared if some jerk decides he's pissed and posts some nazi propaganda, or threats, with a reputable person's e-mail address. I already was an antisemite, and an agent of KGB, thank you very much. Now, how about doing the right thing: make the NANOG list the first one to require signed messages? Somebody has to start. - --vadim -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMtaqSEDODjim2XUVAQFuBwP+N7JhLLT7yFcF8Se7XvfRd9DOPceAa0U5 vvnjbCCEZpq8xWh6H7cMyq3vZdQeFzYnCC6007PQt4AyodJ8DQC77RLL72YthHzz /ZWQdbS7xlJQxsUAFQiZprpeW6cAExRwIiPrKimjx96kvBvufFPeOtLjhV1Vpalo o4e+DHJRGbY= =EMOb -----END PGP SIGNATURE-----

2 1

Agenda items for February
by Susan R. Harris 11 Jan '97

11 Jan '97

Greetings - here are topics we've lined up so far for the Feburary NANOG: Squid update Introduction to Trawhoisd Pathologic applications in the Internet Exchange point updates (10-minute IXP presentations welcome) Consideration of policy: issues of signaling for access and usage End-to-end TCP packet dynamics InterNIC update Non-BGP multihoming for Web sites Internet routing instability Using the IRR to assist in aggregation Are there other topics you'd like to hear about? ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------

3 2

Re: Update on mail bombing threats--not so funny
by Vadim Antonov 10 Jan '97

10 Jan '97

There is no use to attempt to find legal fixes for massive spam and other flooding attacks. The spam sources will simply move out of U.S. and will start loading international circuits with their crap. I.e. the legal cure will only make spam even more annoying, but won't stop anybody. Why won't we concentrate on doing technical solutions? Fortunately, it is relatively easy to get rid of the flooding attacks by reducing their effectiveness to nothing. The solution is source address filtering at edges, to relieve attackers from the benefit of forged source addresses, and reverse lookup authentication in MTAs -- just do not accept any mail coming from an invalid source address, or source address not corresponding to what is in Sender, Reply-To or From field. That will arguably break some setups (for example, when outgoing mail leaves hosts directly, but return mail comes thru a centralized server); but that can be fixed. That scheme is obviously not bullet-proof, but neither are locks on the doors. They do deter crime, though. BTW, the e-mail sender address authentication would also do wonders for non-flooding variety of spammers -- getting tons of angry mail from the targets of the spam does have some effect. Also, it gives ISPs ability to identify abusers, and create a black list of people not to have any business with, and a legitimate reason to refuse service to them. There's a historical precedent in doing source address authentication which initially broke service for a lot of peple, but ultimately made Internet a saner place -- the FTP archive at UUNET at some time started requiring that reverse DNS lookups should provide correct names. Oops -- nobody with broken reverse zones could access it. Now, the question is how to make people to actually implement it. I guess the big providers should consider it in their best interest -- or they'll eventually get politicians and lawyers on their heads. --vadim

5 6

Re: The Cidr Report
by Tony Bates 10 Jan '97

10 Jan '97

Apologies the brokeness of this weeks report. Fixed one to follow. --Tony Tony Bates <tbates(a)cisco.com> writes: * * This is an auto-generated mail on Fri Jan 10 12:00:00 PST 1997 * It is not checked before it leaves my workstation. However, hopefully * you will find this report interesting and will take the time to look * through this to see if you can improve the amount of aggregation you * perform. * [...the rest of stuff deleted...]

1 0

RE: Continental aggregation?
by Jim Fleming 10 Jan '97

10 Jan '97

On Friday, January 10, 1997 4:03 AM, Bradley Dunn[SMTP:bradley@dunn.org] wrote: @ On Fri, 10 Jan 1997, Miguel A.L. Paraz wrote: @ @ > Bradley Dunn wrote: @ > > Is anyone currently aggregating at the continental boundary? @ > @ > Like, how? There isn't a single continent served by a only one provider, @ > with the possible exception of Antarctica. :) @ @ Each continent is served by only one registry, correct? @ It seems to me that there is a flaw in the way the IPv4 address space is viewed with respect to registries. Rather than try to decide what is an ISP or an upstream provider or for that matter a registry, would it not be easier to just agree that... "Anyone or any organiztion who has been allocated a continguous block of IPv4 addresses with at least 16 bits of variable bits is considered to be a *registry* for that block and all addresses in that block. Those addresses can be loaned or leased as that *registry* sees fit subject to the terms and conditions of any agreements that organization may have with one or more superior registries whom allocated the block from a larger continguous block." It seems to me that it is a historic fact and a historic mistake that IP addresses have been allocated to many types of organizations without those organizations understanding the *registry* duties that go with such an allocation. For example. companies that have been allocated a /8 should be encouraged to be registries for that /8 or to pass the block to a company that *is* willing to perform registry services for the block. Registry services consist of: Operation of a IN-ADDR.ARPA Name Server Maintenance of Global IN-ADDR.ARPA Records Registry to Registry Coordination Network Engineering Assistance Routing Agreement Negotiations General Clerical Matters of Registries Registry services have nothing to do with being an NSP, an ISP, an IAP, an IPP, a webmaster, a geek, a guru, or a god. If somehow, IPv4 addresses can be placed in the hands of *registries* then the Internet can get on with the business of cleaning up the address space. In many cases, the same organization that currently claims "ownership" of an IPv4 address block could be considered to be a registry, but there should be a recognition that the registry services are separate from the other missions and operations of the organization. Also, the block of IP addresses that more or less defines a registry, should stay with the registry. The registry can of course be sold or consolidated with a larger registry, but the registry function for that block could remain as an autonimous entity. As food for thought, I have included some notes on how registries can be organized in a hierarchy. Even though registries do not necessarily allocate on octet (byte) boundaries, they could be organized on those boundaries for administrative and revenue flow purposes. The following is only an example, for illustrative purposes. @@@@@@@@@@ IPv8 Registry Revenue Notes @@@@@@@@@@@@ IPv8 addresses are 43 bits. They are 11 (3+8) bits larger than an IPv4 address. This provides two levels of hierarchy above the IPv4 addresses. The 3 bit field is called the Galaxy ID. The 8 bit field is called the Stargate ID. IPv8 addresses with a 0:0:x.x.x.x format are converted IPv4 addresses. IPv4 packets can be viewed as IPv8 packets with an implied 0 in the Galaxy and Stargate fields. =================== 8 Galaxy Registries X:X:x.x.x.x 256 - Stargate Registries per Galaxy X:X:x.x.x.x 256 - Continental Registries per Stargate X:X:X.x.x.x 256 - Island Registries per Continent X:X:X.X.x.x Weighted Sum using double weights downstream 8+512+1024+2048 = 3592 Percentage Calculations 8/3592 = .002227 512/3592 = .142538 1024/3592 = .285077 2048/3592 = .570155 Revenue Percentages to Various Registries 57.0155% to Island Registry 28.5077% to Continental Registry 14.2538% to Stargate Registry 00.2227% to Galaxy Registry ======== EXAMPLE - Based on Lease Rate of $2 per IP Address per Year Typical Class C scenario 256 IP address x $2 - $512/year Gross Revenue from Customer $512 x 57.0155% = $291.919360 to Island Registry $512 x 28.5077% = $145.959424 to Continental Registry $512 x 14.2538% = $41.609601 to Stargate Registry $512 x 00.2227% = $1.14 to Galaxy Registry Theoretical Total Potential Gross Revenues Island Registries handle /16 allocations (16 bit address space to manage) $291.92 x 256 = $74,731.36 Gross Revenue for Island Registry Continental Registries handle /8 allocations (24 bit address space to manage) $145.96 x 65,536 = $9,565,634.56 Gross Revenue for Continental Registry Stargate Registries handle /0 allocations (32 bit address16 space to manage) $41.61 x 16,777,216 = $698,099,957.76 Gross Revenue to Stargate Registry Galaxy Registries handle /-8 allocations (40 bit address space to manage) $1.14 x 4,294,967,296 = $4,896,262,717.44 Gross Revenue to Galaxy Registry ============================================================= -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

2 1

Attendee List
by Pam Ciesla 10 Jan '97

10 Jan '97

Has been updated. If you are not on the list and should be please contact me by e-mail or phone 313-936-0172. Thanks Pam

1 0

Continental aggregation?
by Bradley Dunn 10 Jan '97

10 Jan '97

Is anyone currently aggregating at the continental boundary? -BD

3 3

pre-NANOG road trip -- non-agenda, ignore if offended
by Vince Fuller 10 Jan '97

10 Jan '97

Are there any people heading out early for NANOG who might be interested in a road trip to Lake Tahoe on Saturday/Sunday the 8th/9th? If one leaves by about 5:30AM, it is possible to be on the slopes at Squaw Valley, Alpine Meadows, Heavenly (etc.) by about 9-9:30... Please direct any and all followups to me, not to the list. --Vince

4 3

Re: Update on mail bombing threats--not so funny
by Vadim Antonov 09 Jan '97

09 Jan '97

Allan Chong <allan(a)bellsouth.net> wrote: >One possible solution is just to have recourse after the fact. >If you as an ISP have their credit card/phone billing, and have >a policy that explicitly states that either.... >Even despite the inevitable chargebacks, many spammers would decide that >fighting with the credit card company isn't worth it. How are you proposing collecting any debts from a spammer in Brazilia? BTW, to be able collect such charges you _must_ be able to prove that the spammer have seen the price list. That is kind of hard to do when you don't have spammer's return address. Implied contracts have been commonly found non-binding by the courts (a typical example would be to open a cafe, wait when people walk in and then tell them "our admission fee is $100 -- please pay up, or we call police"). --vadim

1 0

Re: Update on mail bombing threats--not so funny
by Paul Ferguson 09 Jan '97

09 Jan '97

At 01:19 PM 1/9/97 -0800, Vadim Antonov wrote: > >The solution is source address filtering at edges, to relieve attackers >from the benefit of forged source addresses, and reverse lookup Yet another application for draft-ferguson-ingress-filtering-01.txt. :-) - paul >authentication in MTAs -- just do not accept any mail coming from an >invalid source address, or source address not corresponding to what >is in Sender, Reply-To or From field. >

1 0