TDC 375-701 Worksheet 4 2009-09-30 From TCP/IP Protocol Suite, 4th Edition, answer: 8.8, Questions 2, 3 9.8, Questions 3, 7, 15, 16, 17, 18 Q. 8.8.2. ARP fields: hardware type = 16 bits protocol type = 16 bits hardware length = 8 bits protocol length = 8 bits operation = 16 bits sender h/w address = 48 bits (Ethernet source address) sender proto address = 32 bits (IPv4 source address) target h/w address = 48 bits (Ethernet destination address) target proto address = 32 bits (IPv4 destination address) Converting the above to 8-bit bytes we have: 2 + 2 + 1 + 1 + 2 + 6 + 4 + 6 + 4 = 28 bytes If you included an Ethernet header in the final number that would be OK. Q. 8.8.3. This depends on what the hardware and protocol addresses are, but we can assume at a standard Ethernet address size of 48 bits. Since ARP is practically only used for IPv4 on Ethernet these days, we can assume the format is as described in the answer to Q. 8.8.2. Now it depends on the Ethernet framing being used. The most common format is Ethernet II (aka DIX), without any additional IEEE features (e.g. VLAN tagging aka 802.1Q, 802.1p tags). This would mean an additional 18 bytes for the Ethernet framing, so 18 + 28 = 46 bytes. Note, if you're looking at an ARP packet in a trace, its probably not showing you the Ethernet checksum, so you'll only see 42 bytes. We're also ignoring the typical Ethernet preamble and starting frame delimiter. Q. 9.8.3. A variety of plausible answers can be given. The datagram can simply be lost in transit before it reaches Host B. Perhaps due to congestion, link failure, packet filtering or bit errors causing the datagram to be corrupted, failing a checksum test and being silenting discarded. However, note that Host A in many cases will receive some sort of indication depending on the use of upper layer protocols (e.g. TCP). So we'd have to also assume that there is no reliably delivery mechanism in place at upper layers, however if you didn't mention it I won't penalize you since at this stage we haven't really gotten much beyond layer 3. Another plausible answer, similar to a packet filter is if a router in the path is redirecting or blackholing the destination address of Host B. The datagram will simply fail to be delivered and because generally when that sort of thing is done, no indication is given to the sending host (this is often done for security purposes). It might also be that the packet Host A sent was an ICMP packet indicating some error condition. If that packet never reaches its destination, even for such things as a TTL expired, the sender should never know, because a response to such an ICMP message should never be sent. We could also argue that the original packet from host A got to B, but was perhaps never delivered up the stack for a variety of reasons, broken checksum, congestion at Host B, Host B crash, etc. It depends on what your definition of "receives" is. Q. 9.8.7. This could be a huge list depending on how much of the defined ICMP message space we want to cover. For brevity, we'll do just some of the common ones. Also note, its not clear to me what the author means by "nondestination" hosts. Is that a sender or perhaps when a router sends a redirect to another router as in the example I described briefly in class? Technically routers can be "hosts" too, but we won't make the distinction. Furthermore, its all just software so we can "craft" any ICMP packets we want, though this isn't done in normal operation. Destination unreachable Depends on the code. If its a "net", "host" or similar sort of unreachable, its probably generated by a router or some sort of middle box. If its a "protocol" or "port" unreachable, its probably generated by the destination host. Source quench These are generally disabled by routers and hosts these days, and most implementations if not all probably disable them too, but some older UNIX systems in operation may still send them. I believe I had seen Solaris send them in the past, but I think they have been disabled by default for awhile now. HP-UX might still send them. Unsure. The RFCs originally said routers could generate them, but were later updated to say they shouldn't. Hosts would generally be the ones to generate these anyway. Source quench, as it turns out, is an ineffective mechanism to help with congestion. Time Exceeded These would be sent by routers in response to a TTL expiring before reaching its destination. Redirect Routers would send these to either an originating host or in some cases, as the in the case I briefly described in class, to another router somewhere along the path if there is a situation where 3 routers are part of the same subnet and one is in a sort of "triangular" routing situation. Echo/Timestamp request/reply These are generated by sending and destination hosts respectively. Q. 9.8.15. Type: 3 (destination unreachable) Code: 0 (network unreachable) checksum: [ insufficient information to compute ] unused: 0 payload: IPv4 version: 4 header length: [ insufficient information ] service bits: [ insufficient information ] ... [ insufficient information ] source address: 130.45.3.3 destination address: 201.23.4.6 options / payload: [ insufficient information ] Q. 9.8.16. Type: 3 (destination unreachable) Code: 3 (port unreachable) checksum: [ insufficient information to compute ] unused: 0 payload: IP header: [ mostly insufficient information ] Protocol: 6 (TCP) TCP header: Source port: [ insufficient information ] Destination port: 234 [ insufficient information for anything else ] Q. 9.8.17. Type = 3 (destination unreachable). Code = 3 (net unreachable) This message is sent by a router in response to the sender who is sending to a destination that the forwarder (router) does not have a route for. Q. 9.8.18. This is a redirect message for the destination network. The last four bytes in dotted decimal are 17.11.3.2, which is the router that the datagram was forwarded to and the router that the sender should use directly for that destination directly in the future. Note, in practice, even if ICMP redirects are unfiltered, they are often not acted upon as I discussed in the example in class. These pose similar sorts of challenges as source quench. ICMP redirects aren't a great way to "do routing". Also answer the following questions: Q. Discuss how often ARP messages are likely to appear on a LAN of 100 hosts and 1 router. How much ARP traffic would be too much? Does it matter who is sending the ARP traffic? If so, why? This really depends on a number of factors. It depends on how active the hosts are as senders and receivers. If the hosts only send traffic to a remote subnet, the ARP messages will be very moderate. You can generally figure end hosts typically cache their ARP entries for a minute or two, while routers tend to cache their entries from a few minutes up to a few hours. If you do a packet capture on a LAN, you will likely see hosts asks for the router's mapping more often than the router asking for host mappings. Usually routers aren't doing gratuitous ARP so you'll probably expect each of the hundred hosts to ARP once ever couple of minutes. That might be about 100 ARP messages every two minutes. That is really not that much traffic on a typical LAN. However, the larger the subnet, the more ARPs there are. Some organizations have built very "flat" networks, meaning little routing, large prefixes and lots of hosts all in the same subnet. They can get into ARP "storm" situations. This has happened with some types of malware for example, which try to send packets to various local network hosts. Each time they try, they do an ARP request. If they don't get a response, but keep trying to blast packets to those non-existant destinations, well... you can imagine that there are going to be significantly more ARP requests broadcast on the LAN than there should be. Q. Discuss what sorts of security challenges ARP poses. How might you redesign what ARP does? How might you mitigate some of the potential security threats and problems? There have been practically no significant changes to ARP or any movement away from ARP on IPv4. Why do you suppose that is? I've talked about some local network based attacks, including ARP attacks here: Others have done so as well. ARP is susceptible to man in the middle (MitM) attacks, particularly sniffing and spoofing the ARP traffic. The one thing IPX did that was kind of nice in this regard is to simply take the L2 address and make it part of your L3 address. There is no need for ARP in IPX. If you know the IPX address, you know the L2 address. IPv6 supports a similar approach. Since there is no built in authentication in the protocol, to mitigate threats you often have to use the knobs and features outside the protocol in end hosts and network gear. You can hard code ARP mappings, but this is a PITA to manage. Some layer 2 gear support things such as "port security", which limits the number of unique source mac addresses per port. In common switched environments today, you typically have one or a limited number of end hosts on a switch port so this can help spoofing quite a bit. We implemented this at DePaul with some pretty good results. Here is an early write-up (note, some fine points have changed, but the basic ideas remain): The lack of changes to ARP or any core protocol for that reason should not be surprising. Once deployed and widely used, its often difficult to change the installed base, especially if it "works" well enough or without enough pain to justify a change. Q. I contend ICMP is nothing to be scared of and that filtering certain ICMP messages is more trouble than its worth. Discuss the pros and cons of this argument. Allowing ICMP packets, or at least a subset of them as I outlined in the lecture has in my experience been successfully done on a wide scale. Many of those types of messages are indeed more helpful for debugging, network management and operational correctness than than when they are elimiated for mitigating security threats. Some environments may have very stringent information "leak" policies, including even the generation or response to packets as seemingly benign as unreachables. Some environments may wish to cut down on any "unneeded" packets for performance reasons. However, if the site is a popular one, often the complaints about being unable to "ping" or traceroute to it is more trouble than it is worth to disable. Hence, that is likely why many high profile sites such as Yahoo and Google leave it enabled, more as a community service and troubleshooting tool. ISPs often find that when they filter to filter ICMP echo request/reply traffic or traceroute packets to/from their routers, they get a large volume of email asking why their network is "down". So instead, they just leave them enabled. In most decent systems, these are low priority processes and are often internally rate limited so there is already some "hardening" going on in the OS to prevent an unnecessary traffic burden due to an overload of these packet types. Q. Many ICMP messages, typically error response messages tend to include the first 64 bits of the IP datagram payload for the packet that was involved in the error. For TCP and UDP packets, what does this cover? Is it enough to be useful? Would more be better? Worse? Its enough to verify the sending host and often the application involved. While they may little practical value outside of some intermittment application failure, they can be used by researchers examining "spoofed" packets generating unreachable replies. For example, if I spoof (use your source address instead of mine) in a TCP connect to some random closed port on an active host, the active host is likely going to send a port unreachable back to you. While you won't know who spoofed the packet, you will see that someone is impersonating you, and what TCP port they were sent to/from. More data might be useful and this is allowed for, but I don't recall ever seeing it done in practice. I thought I saw some discussion about this somewhere, but I can't find it now. In practice, 64 bits is usually enough to identify the sending app and trigger an application error condition, but in theory in someone might be able to spoof ICMP reachables and cause legitimate connections/apps to fail without some sort of additional verification steps that the unreachable is legitimate. It might be argued that bigger packets mean more wasted capacity and while this is true, it should take as big a packet to send, so its not like its an amplification attack (though it could be used as part of a reflection attack). Q. What are some advantages and disadvantages to running a "default-free" network attached to the public Internet? If your network is well connected, then not having a default is an acceptable thing to do, but if you have a significant outage or lose significant links that cause you to lose some number of routes from a significant peer, you may cut-off large chunks of the network. If you're a small network with few links and little peering, a default-free routing implementation is probably a bad idea for this reason. On the other hand, if you point default to an expensive link/upstream and end up having to use it a lot, that might be more expensive than getting better connectivity and moving closer to a default-free environment. Not having a default route might imply more about routing policies than any technical achievement. There is perhaps some 'status' associated by running a default-free network, but in practice it doesn't mean all that much to most people. An interesting aspect of default-free versus default is what you connectivity looks like compared to someone else. You might actually be able to get to certain prefixes that others can't get to with default, depending on who you default is and what they announce to customers. See this for details: Q. Read: List some reasons why UDP port scanning is harder than TCP scanning. How does ICMP help or hurt? There is no in-band UDP message that tells you whether the port is open or closed like TCP. TCP is connection-oriented so you'll either get a connection setup phase or you won't. With UDP, the application may listen only and never transmit, making it nearly impossible to know remotely if there is even an application receiving the data. The basic approach to UDP port scanning is to rely on ICMP port unreachable messages back for closed ports and the lack of a unreachable when the port is open. The obvious problem is that ICMP may be filtered so how do you tell? Hosts often limit the ICMP unreachable rate too, so you often can't scan as fast as you'd want to for a set of open UDP ports. For UDP applications that might send some sort of response, you can craft application specific messages that will solicit such a message. This might work for UDP apps running on well know ports, but often UDP apps run on random ports so you'd have to send application specific probes to a potentially large set of ports for each application you're interested in. Q. We haven't talked about IPv6 much yet, but you should know that is has 128-bit addresses. How might this pose a challenge for routing and routers? Can you forsee any advantages? The most basic issue would be resource usage for handling the 128-bit addresses. While this is probably do-able with modest upgrades, if needed, what if routing tables become so fragmented that you have many small prefix routes in the table? There are about 300,000 routes in the global Internet routing table now. When I was last doing ops at DePaul, not very long ago, there were less than half that. That's double the growth in a short amount of time. Check out: Examine the BGP table size plots. See the upward trend? At some point the IPv4 tables will only get so large. There have already been router limits people have bumped into. Router upgrades have had to happen from time to time to support an ever increasing number of routes. What is the limit? Maybe about 4 million if people agree that you should expect a /24 to be heard by practically everyone? We'll talk about more specifics and the reason for some of this growth, but what if IPv6 saw a similar trend? What if everyone announced /56 routes? Or even /48's That's a lot of potential routes! What if someone even accidentally leaks a large number of small prefixes into the global table? Something that has happened. Then what? Q. If a router only has in its table the following entries: 140.192.0.0/16 -> eth0 (cost = 100) 140.192.0.0/24 -> eth1 (cost = 200) 140.192.5.0/24 -> eth2 (cost = 100) 140.192.8.0/25 -> eth3 (cost = 50) and packet is destined for 140.192.0.5, out which interface would it go? What if it is destined to 140.192.5.1? 140.191.1.1? It would go out eth1, even though the cost is higher, it is a more specific prefix so it wins. 5.1 would go out eth2. and 1.1. would go out eth0. $Id: worksheet4.txt,v 1.2 2009/10/05 15:40:19 jtk Exp $