- Test - lists.nanog.org

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

PMTU and Broken Servers
by Leo Bicknell 13 May '03

13 May '03

I've recently had the pleasure of troubleshooting a problem I don't normally have to deal with, and the results don't quite make sense to me. I'm hoping someone can enlighten me as to what is going on. A diagram: server---internet---fw---tunnelbox1----tunnelbox2----user The tunnel between the tunnelboxes is a lower (1480) MTU. Originally the user couldn't access some servers, turns out the firewall was filtering ICMP Can't Fragment messages, preventing PMTU from working in the server->user direction (tunnelbox1 would generate Can't Fragement, firewall would filter). That's been corrected. Going to a server I control I see good PMTU in both directions between the server and the user. However, there are still a number of web servers for popular sites that behave just like the firewall was still filtering Can't Fragments. The theory is that the servers are behind a firewall/load balancer that is filtering them on the server side -- but I find it slightly (emphasis on the slightly) that someone would turn on PMTU discovery, and then filter it out right in front of the boxes where they turned it on. Also, it seems to me most DSL users are behind PPPoE links with lower MTU, and should get hit by the same problem. The temporary hack is to have tunnelbox1 clear the DF bit on all incoming packets, which just causes the packets to get fragmented going down the tunnel. A minor performance hit, but it works. This is a new problem to me, but I'm sure people have run into it before. Are the servers really that broken (PMTU enabled, ICMP Can't Fragement filtered)? Does the head end box of DSL services generally do something to work around this (ie, clear the DF bit)? Am I just being an idiot and missing something obvious? -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

7 10

RE: PMTU and Broken Servers
by Russell, David 13 May '03

13 May '03

You should keep in mind that Cisco routers have a limit on the number of ICMP messages they will originate per second. (My mind fails me as to whether it is 3 or 30). So you might lose a few ICMPs because of this. David -----Original Message----- From: Stephen J. Wilcox To: Curtis Maurand Cc: Leo Bicknell; nanog(a)merit.edu Sent: 5/12/03 10:49 AM Subject: Re: PMTU and Broken Servers You mean theres routers which get a large packet and silently drop it rather than return an icmp? Curious as to know which vendors? (read fundementally broken!) Steve On Mon, 12 May 2003, Curtis Maurand wrote: > > > I've had the problem before. Not all routers handle PMTU correctly. > > Curtis > > On Thu, 8 May 2003, Leo Bicknell wrote: > > > > > I've recently had the pleasure of troubleshooting a problem I don't > > normally have to deal with, and the results don't quite make sense > > to me. I'm hoping someone can enlighten me as to what is going on. > > A diagram: > > > > server---internet---fw---tunnelbox1----tunnelbox2----user > > > > The tunnel between the tunnelboxes is a lower (1480) MTU. Originally > > the user couldn't access some servers, turns out the firewall was > > filtering ICMP Can't Fragment messages, preventing PMTU from working > > in the server->user direction (tunnelbox1 would generate Can't > > Fragement, firewall would filter). > > > > That's been corrected. Going to a server I control I see good PMTU > > in both directions between the server and the user. However, there > > are still a number of web servers for popular sites that behave > > just like the firewall was still filtering Can't Fragments. The > > theory is that the servers are behind a firewall/load balancer that > > is filtering them on the server side -- but I find it slightly > > (emphasis on the slightly) that someone would turn on PMTU discovery, > > and then filter it out right in front of the boxes where they turned > > it on. Also, it seems to me most DSL users are behind PPPoE links > > with lower MTU, and should get hit by the same problem. > > > > The temporary hack is to have tunnelbox1 clear the DF bit on all > > incoming packets, which just causes the packets to get fragmented > > going down the tunnel. A minor performance hit, but it works. > > > > This is a new problem to me, but I'm sure people have run into it > > before. Are the servers really that broken (PMTU enabled, ICMP > > Can't Fragement filtered)? Does the head end box of DSL services > > generally do something to work around this (ie, clear the DF bit)? > > Am I just being an idiot and missing something obvious? > > > > > > Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc.

2 1