- Test - lists.nanog.org

RE: FW: /8s and filtering
by Ejay Hire 10 Dec '02

10 Dec '02

Of, you meant the PI micro-allocation for multihoming. That is still being discussed, and hasn't been approved or ratified. This policy states that an ISP can accept multihoming as justification for assigning a /24 to a customer even if they do not meet the immediate 25% 1 year 50% rule. -----Original Message----- From: Alec H. Peterson [mailto:ahp@hilander.com] Sent: Tuesday, December 10, 2002 1:34 PM To: Ejay Hire; nanog(a)merit.edu Subject: RE: FW: /8s and filtering --On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire <ejay.hire(a)isdn.net> wrote: > > Having a /24 doesn't indicate you are a network of any particular size, > ARIN ratified a policy that allows multihoming as justification for a > /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- ahp(a)hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com

1 0

RE: FW: /8s and filtering
by Ejay Hire 10 Dec '02

10 Dec '02

Interesting. Perhaps your source hasn't read the policy updates. Here is the link to ARIN's site, and I have successfully used this as justification for a customer. http://www.arin.net/policy/2001_2.html -ej -----Original Message----- From: Harsha Narayan [mailto:hnarayan@cs.ucsd.edu] Sent: Tuesday, December 10, 2002 1:15 PM To: Ejay Hire Cc: nanog(a)merit.edu Subject: RE: FW: /8s and filtering Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: > > Having a /24 doesn't indicate you are a network of any particular size, > ARIN ratified a policy that allows multihoming as justification for a > /24. > > -ej > > -----Original Message----- > From: N [mailto:nathan@stonekitty.net] > Sent: Tuesday, December 10, 2002 1:01 PM > To: Forrest > Cc: nanog(a)merit.edu > Subject: Re: FW: /8s and filtering > > > comments inline > > On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: > > > > > > >I was also curious about this - if I am a customer who wants to > > > >multihome and can justify only a /24, I would go to an ISP which > has an > > > >allocation from the Class C space rather than one from the Class A > > > >space. > > > > > > It doesn't matter. For all practical purposes, basement > multihomers > > > only > > > care that their two or three providers have their route. > > > > > > Maybe I'm missing something, but what good would it do for someone to > > multihome if only their own providers accept their route, but nobody > else > > does? I realize that their block should be still announced with their > > > ISP's larger aggregate, but what good does this do if your ISP goes > down > > and can't announce the large aggregate. > > For the assigned block to be part of the same aggregate(of both > providers), that implys that the providers sharing the responsibility > for the aggregate. It happens, but is rare. In this case, the providers > must accept more specific routes from each other, that is within the > space being aggregated. If they do not share specifics, one uplink down > will cause a large percentage ~50% for the customer. This scenario is > valid for load balancing, but redundancy is fragile. The only advantage > I see is no limit to prefix length. You can do this with a /28 if you > want... given the above caveats are addressed. > > > If you're a smaller organization, perhaps you'll only have a /23 from > your > > upstream provider. With the filtering that seems to be in place, it > seems > > like the only way you can truly multihome with a /23 is if it happens > to > > be in the old Class C space. Or is this wrong? > > In today's VLSM world... the old classes have no bearing on filtering in > my experience. Prefix length discrimination knows no classfull > boundaries. > > > What seems to be needed is perhaps a /8 set aside by the RIR > specifically > > to allocate to small organizations that wish to multihome that people > > would accept /24 and shorter from. > > There is value in the current filtering of longest prefixes... Allowing > anyone to multihome with BGP, using any network size, is going to double > our BGP tables overnight. Perhaps its good that you must be of some size > to participate in public BGP. Many providers offer redundancy that is > more appropriate for the smaller networks. > > -- > ,N > > ~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~ >

2 1

Re: futureway calls for DDOS on spews
by Mark Segal 10 Dec '02

10 Dec '02

> http://www.merit.edu/mail.archives/nanog/msg05663.html > > smiley be damned; it is what it is: >> Anybody interested in a coordinated denial of service attack? :). >> >>Mark Yup... it is. SPEWS has DOS my network.. I was joking about it, they actually did it! Regards, Mark

1 0

Re: /8s and filtering
by Marshall Eubanks 10 Dec '02

10 Dec '02

Here is one reason for some to care : If you want to do interdomain multicast, and your address space is not announced globally (say because you have a /24 that is not from the swamp), you are likely to be black-holed due to RPF failures (as your unicast and multicast routing is likely to be different). This has caused problems from time to time... Regards Marshall Eubanks On Tuesday, December 10, 2002, at 05:58 AM, David Schwartz wrote: > > >> I was also curious about this - if I am a customer who wants to >> multihome and can justify only a /24, I would go to an ISP >> which has an allocation from the Class C space rather than one from the >> Class A space. > > It doesn't matter. For all practical purposes, basement > multihomers only > care that their two or three providers have their route. > >> Do ISPs get to choose where the allocation comes from? > > Ask your ISP if they'll let you choose. But it usually doesn't > matter, if > you can only justify a /24, you'll find about the same filtering > policies in > both traditional class A space and class C space. > > But again, it doesn't matter. So long as each of your providers > will honor > your route (and why wouldn't they, you're paying them to) you > shouldn't have > a problem. > > Just pick your most reliable provider, and the one you're pretty > sure you're > going to stay with the longest, and get your IP space from them. Make > sure > they don't mind you advertising your block through other providers. > > And give some thought to hiring a competent consultant to help > you. You can > hire a consultant even if you are the consultant. In fact, no competent > consultant would do otherwise outside his or her area of expertise. > Don't > learn to multihome at your client's expense. ;) > > DS > > > Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html

2 1

/8s and filtering
by Harsha Narayan 10 Dec '02

10 Dec '02

Hello, Currently APNIC's policy means that if an organization can fully use a /26 (since 25% of /24=/26 and to satisfy the multihoming requirement the organization will need to have a prefix advertised by two or more ISPs) it can get a multihoming assignment from APNIC. If Class C /8s are over and ISPs maintain their filtering policies, the bar would be raised to fully using a /24 instead (since 25% of /22 = /24 and filtering in Class A is done at /22). 8 of the 9 APNIC /8s are from the Class C space. Only one is from the Class A space. However there are only three untouched /8s left in the Class C space - 197/8, 222/8, 223/8. Actually, I wanted to know if the filtering policies will change to accommodate this - i.e. will /24s be allowed in the Class A space? I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. Do ISPs get to choose where the allocation comes from? Harsha.

3 2

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> > I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP > > directories for unallocated IP space at the largest aggregate level. I'd > > also like to see them all dump the quirky and antiquated whois protocol > > and move to LDAP as the standard way of querying their directories. The > Insisting on LDAP is likely to kill your proposal before it gets off the > ground. RPSL works fine. If you want LDAP, you can certainly mirror > via the IRRD mirroring protocol, and store however is most useful > to you. I disagree. LDAP is a widespread technology and RPSL/IRRD/RADB is not. The registries can hire people with LDAP experience or send people on LDAP training courses. They can get advice and support from LDAP consultants. And if the registries tell their staff to learn LDAP, then the staff will be motivated to do it well since LDAP knowledge is a marketable skill. The RIRs should be looking at LDAP as the core technology for offering their directory services. We've already tried the RADB/RPSL/IRRD/whois/rwhois route for years and it has failed. Only a few people have bothered to learn most of these technologies and many network operators don't use any of it in an automated fashion. Just recently there was a lot of discussion about the new ARIN whois format and a lot of this revolved around how to make it easier to parse for automated systems. That's like running a mailing list by typing in messages, printing them out, faxing them to UMich where they are scanned and run through OCR, and then emailed to you. Here's how an LDAP directory works. There is a SWIP template form on an ARIN web page. You type the appropriate bits of info into the appropriate boxes and press the submit button. An ARIN CGI or webapp places each field into a relational database. Once a day, they dump any database changes into their LDAP directory. Now when you or your admin scripts query the LDAP directory, each bit of data is received as a separate identifiable field. No more parsing. In fact, you can tell the LDAP server to only send the bits of data that you are interested in. Rather than trying to reinvent LDAP by ourselves it makes an awful lot more sense to leverage the efforts of the hundreds of people at Netscape, SUN, IBM and many universities who have worked over many years to make LDAP version 3 into a very usable tool. LDAP directories are already integral parts of running many large networks in universities and corporations. We should use it in the global Internet as well. -- Michael Dillon

4 3

RE: Spam. Again.. -- and blocking net blocks?
by Mark Segal 10 Dec '02

10 Dec '02

We did swip the block to the isp (as an assignment, not allocation).. That is the problem, they kept recursively looking up the assignment.. Maybe they should block 64/8 or maybe 0/0 :). Anybody interested in a coordinated denial of service attack? :). Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 > -----Original Message----- > From: Michael.Dillon(a)radianz.com [mailto:Michael.Dillon@radianz.com] > Sent: December 10, 2002 10:36 AM > To: MSegal(a)FUTUREWAY.CA > Cc: nanog(a)nanog.org; owner-nanog(a)merit.edu > Subject: Re: Spam. Again.. -- and blocking net blocks? > > > > Problem: > > For some reason, spews has decided to now block one of our > /19.. Ie no > mail > > server in the /19 can send mail. > > > Questions: > > 1) How do we smack some sense into spews? > > Make it easy for them to identify the fact that your downstream ISP > customer has allocated that /32 to a separate organisation. > This is what > referral whois was supposed to do but it never happened because > development of the tools fizzled out. > > If SPEWS could plug guilty IP addresses into an automated > tool and come up > with an accurate identification of which neighboring IP > addresses were > tainted and which were not, then they wouldn't use such crude > techniques. > > Imagine a tool which queries the IANA root LDAP server for an > IP address. > The IANA server refers them to ARIN's LDAP server because > this comes from > a /8 that was allocated to ARIN. Now ARIN's server identifies > that this > address is in your /19 so it refers SPEWS to your own LDAP > server. Your > server identifies your customer ISP as the owner of the > block, or if your > customer has been keeping the records up to date with a simple LDAP > client, your server would identify that the guilty party is > indeed only on > one IP address. > > Of course, this won't stop SPEWS from blacklisting you. But > it enables > SPEWS to quickly identify the organization (your customer > ISP) that has a > business relationship with the offender so that SPEWS is more > likely to > focus their attentions on these two parties. > > > 2) Does anyone else see a HUGE problem with listing a /19 because > > there > is > > one /32 of a spam advertised website? When did this start > happening? > > It's a free country, you can't stop people like the SPEWS group from > expressing their opinions. As long as people are satisfied with crude > tools for mapping IP address to owner, this kind of thing > will continue to > happen. > > --Michael Dillon >

1 0

Re: Spam. Again.. -- and blocking net blocks?
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> Problem: > For some reason, spews has decided to now block one of our /19.. Ie no mail > server in the /19 can send mail. > Questions: > 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. > 2) Does anyone else see a HUGE problem with listing a /19 because there is > one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon

1 0

Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> >> How do we get software vendors (free, pay, virus) to distribute > >> software with appropriate defaults? > michael> Second step, publish a directory. I.e. detect the > michael> non-conforming devices and publish their IP addresses in an > michael> LDAP server. > Let me get this straight, you are suggesting that the way to fix the > problem that there are potentially millions of insecure machines > connected to the Internet is to *PUBLISH* the IP addresses of all of > them in an easy to parse format? Cute. Yes, more or less. I am suggesting that people who have *detected* a vulnerability and wish to publicize this fact should publish their lists in a standard format and make it available via a standard protocol like LDAP. Since the number of *detected* vulnerable hosts is a lot lower than the total number of vulnerable hosts this is not as big as you think. And since one has to *detect* the vulnerability before publishing it, the scaling issue with detection is more of an issue than with publishing. Besides LDAP has proven to be scalable to very large databases. LDAP was developed as a light-weight system so that it could be scaled massively. > Don't tell me...we'll be able to pull the vulnerability that got the > hosts in the list too, so we can verify that "our" machines are, > indeed, misconfigured? ;-) Sure, why not? If someone is going to the trouble of collecting the information and publishing it, then they should publish this as well. After all, when you query an LDAP server you can specify which fields you want to retrieve. Applications that don't need the vulnerability info won't bother asking for it. --Michael Dillon

1 0

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> ARIN explicitly does not guarantee routability of prefixes it assigns. If > service providers choose to filter ARIN allocations, then that is an > operational decision. I really don't see what action you expect ARIN to > take along these lines. Clearly you haven't been following the ppml mailing list. As I have already suggested on that list, ARIN could publish an authoritative directory of all unallocated IP address space at the largest aggregate level in a form that makes it easy for network operators to incorporate into their martian filters. Fast forward to the time when everyone gets their filters directly or indirectly hooked up to the RIR's authoritative directory and this problem goes away. Yes, ARIN cannot directly make the problem go away but ARIN definitely can take action that will lead to a solution of the problem of martian filters. The only thing ARIN would have to guarantee is that their directory is authoritative, complete and updated at least once every 24 hours. The base directory could be published in LDAP form with a BGP version for people who find it easier to work with this. And no, I'm not suggested that anyone connect their productions routers directly to an ARIN BGP feed. Smaller network operators will probably find such a direct BGP feed to be convenient but I expect all the larger network operators to use the BGP feed as a way of monitoring for changes which would be reviewed by some clueful operator before building the filters. That should not be a problem assuming that ARIN issues addresses every weekday. --Michael Dillon

8 12