- NANOG - lists.nanog.org

Re: Fwd: Club-Internet/T-Online France
by Dan Hollis 14 May '03

14 May '03

On Tue, 13 May 2003, Thomas Kuiper wrote: > Well, what kind of abuse? > The whole 212.194.0.0/16 is customer ADSL access > and abuse(a)club-internet.fr works very well. No, it doesn't. The abuse(a)club-internet.fr denied that 212.194.0.0/16 belongs to them, and they told me to "talk to the real provider, not club-internet.fr". -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

4 5

Detection and preferential dropping of high bandwidth unresponsive flows
by Sean Donelan 14 May '03

14 May '03

The IEEE international conference on communications this week has several technical papers of interest to network security, although the most relevant weren't labeled network security. Detection and Preferential Dropping of High Bandwidth Unresponsive Flows by Chatranon, Labrador and Banerjee. Controlling Malicious Sources at Internet gateways by Chhabra, Joh, Saran and Shorey. But there are still issues about loading the bottleneck with even more processing during periods of extreme stress, handling distributed management domains, and handling distributed attacks. Scale affects everything on the Internet, including the response.

1 0

RE: Using Policy Routing to stop DoS attacks
by Christopher L. Morrow 14 May '03

14 May '03

On Wed, 14 May 2003, Lars Higham wrote: > Well, this is also from the docs: > > Unicast reverse path-forwarding (uRPF) check is a tool to reduce > forwarding of IP packets that may be spoofing an address. A uRPF check > performs a route table lookup on an IP packet's source address, and > checks the incoming interface. The router determines whether the packet > is arriving from a path that the sender would use to reach the > destination. If the packet is from a valid path, the router forwards the > packet to the destination address. If it is not from a valid path, the > router discards the packet. uRPF is supported for both Internet Protocol > Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) protocol > families. > > Do you have more specific questions about the implementation? The original question was along the lines of: "On a cisco the blackholed SOURCE address will get dumped in uRPF, is that possible on the Juniper also?" > > Regards, > Lars > > -----Original Message----- > From: Christopher L. Morrow [mailto:chris@UU.NET] > Sent: Wednesday, May 14, 2003 9:37 AM > To: Lars Higham > Cc: 'Stefan Mink'; 'Haesu'; jtk(a)aharp.is-net.depaul.edu; nanog(a)merit.edu > Subject: RE: Using Policy Routing to stop DoS attacks > > > > > On Wed, 14 May 2003, Lars Higham wrote: > > > Sorry, > > > > I misunderstood the earlier question - > > > > >From the docs: > > To enable unicast RPF check, include the unicast-reverse-path > > statement at the [edit routing-options forwarding-table] hierarchy > > level: [edit] routing-options { > > forwarding-table{ > > unicast-reverse-path (active-paths | feasible-paths); > > } > > } > > > > yes, the config bits are on the website.... BUT, not the details of the > implementation :) So, does uRPF on a juniper work the same as the > cisco?? > :) > > > Regards, > > Lars Higham > > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf > > Of Christopher L. Morrow > > Sent: Tuesday, May 13, 2003 2:00 AM > > To: Stefan Mink > > Cc: Haesu; jtk(a)aharp.is-net.depaul.edu; nanog(a)merit.edu > > Subject: Re: Using Policy Routing to stop DoS attacks > > > > > > > > > > On Mon, 12 May 2003, Stefan Mink wrote: > > > > > On Tue, Mar 25, 2003 at 04:58:59PM +0000, Christopher L. Morrow > > > wrote: > > > > you could hold blackhole routes for these destinations in your > > > > route > > table > > > > (local or bgp) So long as the destination for the source is bad > > (null for > > > > instance) the traffic would get dropped. I believe the proper > > > > terms > > from > > > > cisco for this are: "So long as the adjacency is invalid" ... > > > > > > is there a way to make this source-blackhole-routing work on J's too > > > > (does this work with discard-routes too)? > > > > > > > I believe someone from Juniper should likely answer this question :) > > As I understand the setup from a Cisco perspective (and someone from > > Cisco can > > correct me if I get it wrong). uRPF works in such a way that if the > > source > > address's destination has an invalid FIB entry (or no entry, or Null0) > > the > > packets are dropped. > > > > Perhaps Juniper implemented it this way? I have not checked anymore > > closely than this. Sorry. :( > > >

1 0

RE: Using Policy Routing to stop DoS attacks
by Christopher L. Morrow 14 May '03

14 May '03

On Wed, 14 May 2003, Lars Higham wrote: > Sorry, > > I misunderstood the earlier question - > > >From the docs: > To enable unicast RPF check, include the unicast-reverse-path statement > at the [edit routing-options forwarding-table] hierarchy level: > [edit] routing-options { > forwarding-table{ > unicast-reverse-path (active-paths | feasible-paths); > } > } > yes, the config bits are on the website.... BUT, not the details of the implementation :) So, does uRPF on a juniper work the same as the cisco?? :) > Regards, > Lars Higham > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Christopher L. Morrow > Sent: Tuesday, May 13, 2003 2:00 AM > To: Stefan Mink > Cc: Haesu; jtk(a)aharp.is-net.depaul.edu; nanog(a)merit.edu > Subject: Re: Using Policy Routing to stop DoS attacks > > > > > On Mon, 12 May 2003, Stefan Mink wrote: > > > On Tue, Mar 25, 2003 at 04:58:59PM +0000, Christopher L. Morrow wrote: > > > you could hold blackhole routes for these destinations in your route > table > > > (local or bgp) So long as the destination for the source is bad > (null for > > > instance) the traffic would get dropped. I believe the proper terms > from > > > cisco for this are: "So long as the adjacency is invalid" ... > > > > is there a way to make this source-blackhole-routing work > > on J's too (does this work with discard-routes too)? > > > > I believe someone from Juniper should likely answer this question :) As > I > understand the setup from a Cisco perspective (and someone from Cisco > can > correct me if I get it wrong). uRPF works in such a way that if the > source > address's destination has an invalid FIB entry (or no entry, or Null0) > the > packets are dropped. > > Perhaps Juniper implemented it this way? I have not checked anymore > closely than this. Sorry. :( >

1 0

Another possibly hijacked block - 160.116.0.0/16
by william＠elan.net 14 May '03

14 May '03

Hello, I want to alert you everyone on the maillist regarding ip block 160.116.0.0/16, the block was announced by HE and XO previously (in my own routing table it is not showing right now) so these organizations are probably aware of the unsolicited emails that were coming out of this block and chose to not announce it any more. I'm hoping other organizations that maybe approaced to announce the block would be alerted by this email and not let it show up on tne net again. I'm also trying to find out more about if this block is really hijacked or not. The address listed in ARIN database is "P.O. Box 261333, Excom, South Africa" and as far as I can tell this address is the one that was used originally (at least as of 1994) and when block first appeared on the net, it was announced through AS1957. I also tracked that network in ARIN database was originally named "Affiliated Computing Services--Uninet Project" which means it had some associated with UNINET which is/was South Africa's education/university network (www.tenet.ac.za) kind of like NSFNET was in US as far as I can remember. As far as I can see most of other organizations associated with uninet are being announced through AS3741 (this includes blocks 160.114.0.0/16, 160.115.0.0/16, 160.118.0.0/16, and many of the of the blocks from 196.11.0.0/16). Uninet/Tenet itself is using ip block 196.21.0.0/16 and several others and these are and announced through AS2018 (and none of these are AS## 1228 - 1332 which are the as# in arin records for uninet, anyway its probably just historical records). I can not find any information about original domain that organization that had this block may have had but currently it seems to be affiliatedcomputing.com and record is pointing to the same address as arin block but I can not confirm if it was this way originally or if the domain was reregistered (but I'm sure whoever controls the domain now is involved in unsolicited email). Now if anybody is here from South Africa, possibly UNINET/TENET or somebody associated with AS1957 or AS3741 and knows anything about this block please reply and if something wrong did happen as far as ARIN records, we need to let them know. -- William Leibzon Elan Communications william(a)elan.net

3 7

Direct allocations solutions
by �� 13 May '03

13 May '03

I would like to hear the opinion of the group on solutions for the ARIN minimum /20 justification. In my opinion IP growth and the demand for direct allocations conflict each other. My small business has a minimal number of hosts however that is no reason I shouldn't provide the highest level of service for myself and my customers, specifically solutions for single points of failure. Upon multi-homing I wished to purchase IP's directly from ARIN to minimize the impact I might experience if my primary provider (which controls my IP's) might go under, or for any other reason become unable to provide service. I was obviously unable to _truthfully_ justify so I slowly made an attempt to increase my real host count by no longer making a best effort to minimize my IP usage. I am a strong believe in helping for a cause, however without lying, cheating, or stealing how do multi-homed networks with only /22 utilization obtain the benefits of a direct allocation? I partially understand ARIN's reasoning and policies for not providing smaller blocks, and have been reading about portable blocks, however its obviously been a long standing problem for others in my position to find a solution without faking/inflating justifications. My primary solution is the idea of sharing a /20 with another individual in my similar position. This obviously has faults, however I believe it is an increased safety net from my current situation. Are there are rules/policies that would prohibit this? If not, why have I not seen "IP Brokers/Resellers"? To conclude, there has been a lot of talk on several mailing lists about quality vs. quantity of bandwidth, I personally am hosted on cogent which has provided the service I expected (taking into account the price), however the financial situation of several ISP's is critical, which only emphasizes the overall demand of stable IP blocks. If the thread concludes IP blocks can be shared, I hope to start some type of IP broker mailing list or similar, to solve this problem for others. If anyone is interested in this or sharing an IP block please contact me off-list. Also, I would be interested to hear what ARIN has to say as I honestly have not contacted them about this yet, and unfortunately decided to get the response from the public first. Thank you, Matt _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

4 3

arin ip request info
by Steve Rude 13 May '03

13 May '03

Can someone please send me a copy of your arin request for additional IP space? We have filled our initial ISP allocation, and we want to follow the proper procedure for the least delay. I figure if I see someone's request that has successfully requested more space, then I will have the least delays in the allocation process. Also, no, I don't want to buy your /16, go away. :) TIA. Steve Rude

5 4

RE: Club-Internet/T-Online France
by Dan Hollis 13 May '03

13 May '03

On Tue, 13 May 2003, Mourad BERKANE wrote: > abuse(a)club-internet.fr Already tried it. They deny that 212.194.0.0 - 212.194.191.255 netblock is theirs. I'm looking for a more clueful contact, since their abusedesk is clueless. -Dan [-] Omae no subete no kichi wa ore no mono da. [-]

1 0

Re: Using Policy Routing to stop DoS attacks
by Stefan Mink 13 May '03

13 May '03

On Mon, May 12, 2003 at 04:38:30PM +0530, Lars Higham wrote: > Ya, you configure the next-hop of the source route(s) to discard - just if I got this right: On both, Juniper and Cisco, if the source OR destination address is reachable via [NULL0|Discard], the packet gets dropped if RPF is enabled on the interface. Does this work in loose mode too? Thanx && tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA

2 1

Procket Routers
by Eden Akhavi 13 May '03

13 May '03

If anyone has had any experiences of Procket's products good or bad, please contact me off list. We are investigating their products at the moment and it would be useful to hear about any testing you have done. Thanks Eden

2 1