At 09:39 AM 1/26/02, bergenpeak wrote: >Thanks for the responses so far. One more variation to this question. >What if there was an application on my network that instead of blocking, >I wanted to control the amount of bandwidth it consumed. One might >define an ACL to identify the traffic by L4 port and map this traffic to >a rate-limiting mechanism.
That sounds like custom queuing, which does have a fragment keyword. Look up "queue-list protocol" in the documentation index for more info, (although don't expect Cisco documentation to actually explain anything as advanced as this. ;-) Cisco also has numerous traffic policing and shaping features. I scanned a few of those documents and didn't find anything about fragments though. As you may know, an IP fragment doesn't have any Layer-4 identification in it. If the router includes the fragments in any fancy shaping or queuing algorithms, then it must keep track of the IP identification. The IP ID is the same on all the fragments. This would require the router to be stateful and possibly slow it down. Of course, if you're fooling with queuing, then the router is maybe already slow. A fast router with well-matched interface speeds doesn't need to queue packets. If you want a definite answer to this, you could try doing more research on Cisco's site (good luck!) or try some experimentation. You can cause fragmentation to happen by sending an oversized ping. In the real world, most applications don't send packets that need fragmentation. NFS used to. I don't think it does anymore. The example that people always use for fragmentation is a host on Token Ring sending to a host on Ethernet. In actuality, very few applications took advantage of Token Ring's ability to send larger frame sizes. Fragmentation is fraught with problems. It is generally avoided. Priscilla >Now, if the application generates data in such a way that it causes the >data to be mostly carried in IP fragements, this ACL will not identify >all >packets associated with the application. Rate-limiting will only >manage >the bandwidth of the first IP packet in each segement. This may or may >not >work in throttling the traffic. > >Does using the ACL "fragement" option help here or would this require >moving to >some other session identification mechanism? > >(I've got no idea how likely standard applications are to send segements >sufficiently large so that IP fragementation occurs...) > >Thanks > > >Sean Knox wrote: > > > > In addition to Priscilla's comments, sending IP/TCP/UDP fragments is a > > useful way to fingerprint a host's OS. The response from the fragmented > > packet(s) can be used as a clue to determine what OS/platform is running on > > the other end. Nmap, among many other tools, has options to send fragmented > > packets in a variety of ways. Check out http://www.insecure.org for some > > informative white papers on OS fingerprinting. > > > > - Sean > > > > -----Original Message----- > > From: bergenpeak [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 23, 2002 4:18 AM > > To: [EMAIL PROTECTED] > > Subject: ACLs, TCP segements, and the "fragments" keyword [7:32922] > > > > Looking at extended ACLs I see there's an option to define ACL > > statements which can key on whether the IP packet contains a > > fragment. > > > > Besides for NAT purposes, could someone provide me with a scenario > > where one would need develop an ACL to key on IP packets carrying > > fragements? I'd be particularly interested in situations where one > > might want to block a TCP application and decided that one had to > > block traffic to the TCP port as well as fragments going to the server. > > > > Thanks ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=33305&t=32922 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
