On Thu, 2011-01-06 at 13:30 -0500, Lamar Owen wrote: > On Wednesday, January 05, 2011 07:51:19 pm Michael H. Warfield wrote: > > On Wed, 2011-01-05 at 17:26 -0500, Lamar Owen wrote: > > > I refer in particular to Cisco IOS NAT, IOS 12.4(23) mainline on a > > > 7206/NPE-G1, using NAT pools and overloading. Incoming packets > > > addressed to the outside interface that don't match the flows that the > > > router knows about get dropped. > > > What you say is true but is equally true if you retain the stateful > > firewall at the heart of the NAT engine and eliminate the NAT. > > The Cisco NAT is by default stateless; you have to specifically > configure stateful NAT (on platforms that support it, and if your IOS > feature set has that feature), but that mostly just gets you HSRP > resilience for NAT; the packet translation itself is stateless (and > hardware accelerated on some platforms, especially those with PXF > which can do the IP header rewrites at wire speed). It's actually not that terribly difficult to do the rewrites at wire speed. Years ago, I sat through a presentation done by one of the original people with the PIX hockey puck NAT long before Cisco bought them out. The trick is that you don't validate or recalculate the checksum over the entire packet. You just calculate the difference created by the few fields you change and add the difference into the existing checksum. If the checksum was bad coming it, it's bad going out but if it's good coming in, it's good going out. So you're really just altering 6 bytes (port and address), taking the different between the sum of those 6 bytes from the sum of the six originals, and correcting the sum in the header and never even look at the payload. Your memory speed over the whole packet moving it is going to take longer. Your hash table mapping lookup is going to take longer than summing those two sets of numbers, subtracting the results, and adding with the original sum. Piece of cake and quite a cute trick of insight there on their part. > > 'Stateful Firewalling' in Cisco-land is 'packet inspection' or even > deep packet inspection, and is an additional feature set (and an > additional cost for the IOS image), but images which cannot do > stateful inspection can do NAT overload. Stateful firewalling in that > context is also referred to as CBAC (Context-based Access Control). > This inspection is a control-plane activity that writes ACLs, whereas > NAT happens in the data (forwarding) plane, as a separate step from > the ACL application (also in the forwarding plane). You're just talking nameology here with this. Call it what you want, there is still a state engine at the heart of the NAT driving the NAT mappings. It's that state engine that adds a table entry when an outgoing packet initiates a connection entry and it's that state engine that eventually tears down that connection in the table when it is no longer in use. However specific "Cisco" uses the term "Stateful Firewalling" or "Stateful Inspection" (or loosely they use the term "deep packet inspection" when it isn't very "deep") the fact remains that the heart of a NAT/NAT-PT is a state engine. They may not call it a firewall and the port mappings themselves may not be stateful once the table entry is made, but it is still a state engine managing the table entries. The individual packet translations equally do not have to be stateful but they do have to look up the mappings in a table of entries which are maintained by a state engine. You can also easily have the translations taking place out on an ASIC interface card but have the state engine running on the management CPU updating the tables in the cards. If the mappings are dynamic (IOW, you don't have to code them in yourself) then there is a state engine which establishes them and removes them. It may (or may not) simplier than the state engine at the heart of a stateful firewall but it is still a state engine. > > The NAT > > is not what's giving you this protection. It's the stateful nature of > > THAT particular NAT which is the same as as a linear stateful firewall. > > No difference. And other forms of NAT do not enjoy this. > [snip valid NAT config that is set up to not provide that benefit] > > > NAT, in and of itself, is not providing the security. It's the state > > engine at the heart of most (but not all) NAT devices and all stateful > > firewalls. It's not the NAT, it's the firewall. > > NAT in cisco IOS is stateless unless certain features are turned on. The forwarding plane as part of the switching process performs the header translation (if one exists) and then routes; if there is no destination for the route it's blackholed, or hairpinned (depending on configuration). > > That is, given the NAT translation table snippet: > > tcp 10.10.10.10:52650 192.168.1.118:52650 74.125.67.99:80 74.125.67.99:80 > tcp 10.10.10.10:1769 192.168.1.166:1769 74.125.67.99:80 74.125.67.99:80 > > And assuming no other translations are in the table, 74.125.67.99 > could scan 10.10.10.10 all it wants; only packets to ports 52650 and > 1769 will get statelessly translated (bidirectionally; the return > packets also get translated for a tcp translation) to the respective > addresses on the inside, and only to those ports; all other packets to > that 10.10.10.10 address will be left untranslated and routed to the > interface with 10.10.10.10 on its subnet. That could be a Null device > for blackholing purposes, or it could be a honeynet, or it could even > be a real host. Please see the Cisco document entitled 'NAT Order of > Operation' (the direct link is long, and can change at seemingly > random times for some reason) for more detail and pointers to how NAT > works in IOS. > > The above example table is part of the following example IOS NAT > config (both derived from what I have here, with addresses changed): > > ip nat pool metro-e 10.10.10.1 10.10.10.13 netmask 255.255.255.240 > ip nat inside source list 1 pool metro-e mapping-id 10 overload > > This is not firewalling (nothing is blocked by the NAT itself; but > only what's in the table gets translated), and is not stateful. The > addresses that get added to the table have an associated access-list, > but that's just a convenient way to list addresses; a route-map is > also a possible source of addresses for the NAT operation (ip nat > inside source route-map ..... ). It may not be a firewall, per se, but it still contains a state engine. > And I realize that I'm describing what some call port address > translation (PAT) or even as NAT-PT (network address translation - > port translation), but it's all configured in the common NAT engine. > NAT is a far simpler operation than stateful firewalling; packet > inspection to overcome some of the broken protocols that are > NAT-hostile brings in the stateful firewall engine that makes things > like CBAC possible. NAT only has to deal with address and port number > translation in the IP header, and, as mentioned, can be done in > pattern matching hardware like Cisco's PXF. Still has a state engine running the mapping tables. The hardware in the Ciscos matches tables and applies those transforms but it's still a state engine on the host processor that's managing it, what ever Cisco is calling it. Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
