>> [Ken] This may be feasible for stateful devices, but does not work >> for stateless devices (QOS/Statistics/auditing functions). Even in >> stateful devices, it requires coupling between observation on flows >> and the associated heuristics cache engine, which creates an >> additional overhead. > >As the draft says this is mostly meant for stateful devices, and that >has been the main goal for the document. The charter says: > >"A standards-track mechanism that allows an intermediary device, such >as a firewall or intrusion detection system ..." > >I.e. the main goal was set to be on the devices doing deeper >inspection i.e. firewalls and intrusion detection systems. > >At least my conclusion on the list when we discussed on the usage >cases were for that kind of stateful devices.
[Ken] I think the charter is device independent and needs to accommodate any type of device that requires access to the data - stateless or stateful. Otherwise, we have a partial solution. I was under the impression that this charter was to provide intermediate device traffic visibility, irrespective of the type of device that needs this visibility - or am I missing something? > >Are QOS and auditing devices really stateless? > >I would expect QOS devices to have all kind of reservation systems and >so on and for those I would expect them to be keeping state? [Ken] QoS may be applied on the need of the underlying service. E.g. A static rule that indicates that I place voice traffic in a priority queue over data traffic may be sufficient as a basic stateless rule. Auditing (logging) is another example where you may want to capture all TCP or UDP traffic - e.g. for diagnostics or other analysis. There is no need for any state correlation between connections / flows - this is just a dumb filter based on protocols / ports. > >For the auditing I have been using I have usually enabled auditing of >new connections, not all packets, thus all my auditing systems I have >set up have been keeping state. What kind of usage is completely >stateless auditing devices used for your example of 10Gbps links? [Ken] Stateless firewall is one example to filter unwanted network traffic. Please see separate message on this topic on the ML. > >Statistics devices could even be stateless, but is that really >something we should aim for? I.e. to wait for 5-10 years before we can >use our stateless statistics devices, compared to use stateful >statistics devices for doing the thing this or next year. [Ken] We have been through the deployment timeframe arguments before and it looks like we are going in circles here. It is speculative to say how long one solution will take to be adopted instead of another. This depends on a number of factors - e.g. some network appliance vendors have indicated that they will not employ heuristics in their network devices due the cost / complexity, but prefer a more deterministic approach, whereas others may be more willing to add this support and charge a premium for the appliances. > > >> [Ken] These require timestamps (or other ordering / metric based >> approaches) and monitoring to ensure the cache is up to date. > >Stateful devices do already have all that. [Ken] Stateless devices may not! > >> Furthermore, it may also provide opportunities for adversaries to >> use periodic replays to provide cache thrash and associated overhead >> in re-executing heuristics engines. > >As far as I have understood we are still talking about the inside one >enterprice network, not internet as whole. If they do have untrusted >users inside (i.e. attackers), they should enable encryption, thus all >this is not really a point. > >As ESP-NULL does not offer confidentiality it can only be used in >trusted environments, where the denial-of-service attacks against the >device in the middle should not be big problem. [Ken] Why is DoS not a big problem, especially if we generate a new DoS opportunity on a new 'cache' in the network device? BTW, insider threats are on the rise according to various public reports, so should not be discounted. This is one of the motivations of employing security, even within the Enterprise. > >> I am not convinced that SW based solutions will scale 10Gbps >> solutions, let alone future 40/100Gbps bandwidth requirements, >> especially at these network 'choke' points, so a HW orientated >> solution may be desirable...which brings us back to >> cost/complexity... > >Limits for software based heuristics are not really related to the >line speed, but number of new IPsec connections per second going >through the device. [Ken] My point was that based on a large # of connections (and potentially cache thrashing, resulting in cache evictions), the SW burden for executing the heuristics engines may still be large. Also, cache will be of a finite size and will not scale to larger and larger connections / loads. > >The line speed do affect the HW based flow cache lookup (i.e. the >appendix A.1 fastpath part of the processing), but that is doable even >at 10Gbps speed, as it basically does same thing as normal stateful >firewall rules (i.e. fetch flow information based on IP address pair, >protocol and in this SPI number instead of port numbers). > >> >As here the heuristics is run on the same device which is running the >> >deep inspection, they do already require methods of transferring that >> >deep inspection state from one device to another, and moving the IPsec >> >SPI cache state at the same time should not be a problem. >> >> [Ken] But again, this is additional work, which can be avoided if we have >no state. > >Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV >len and IV len) per flow more when you transfer the whole deep >inspection state from device to other (which might include whole TCP >transmission window, which is around 64kB or so), so the increase of >additional work is about 0.009% (actually it is normally even less, as >TCP state is per TCP flow, and usually one IPsec flow has multiple TCP >flows inside, but in this case I took the worst case scenario, where >each IPsec flow have exactly one TCP flow inside). > [Ken] This may be acceptable on some stateful devices, especially those that maintain TCP based flows, but may not be acceptable for stateless or UDP based flows. >I do not really consider that to really be matter. > >(Doing deep inspection on TCP streams usually do require >reconstructing TCP stream in fully including dropped and retransmitted >packets. Otherwise there are attacks where you only inspect packet >which never reaches the end node (attacker causes it to be dropped), >and the retransmission packet is different than the first packet and >if you let that pass to the end node, attacker managed to get >uninspected packet through. Solution is that you either do the >retransmissions from your internal data or you verify that >retransmissions sent by the original node contains same data than >original packet, both of them do require you keep the TCP transmission >window data. This text is here just to explain that doing deep >inspection (for IDS or IPS) on TCP stream is very costly operation and >heuristics do have minimal cost compared to them.) > >> >> Auditing / logging / sniffing / sampling are some examples of >> >> stateless devices that do require to peek in the packets. Probably >> >> lots more also, so look for others to provide examples... >> > >> >As those do not affect the forwarding of the packet, then the >> >reliability requirements for them is much lower, meaning that they can >> >also work without storing any state, and running heuristics for per >> >packet basis. That of course do require implementing the heuristics on >> >the hardware if we are talking about gigabit links or faster. My guess >> >is that without any hardware support and only using software with >> >modern CPU you can probably process more than 100MBit/s, but most >> >likely not full 1GBit/s speed. >> >> [Ken] Agreed on the need to implementing heuristics in HW, but this >> contradicts the original 'benefit' of heuristics, where heuristics >> engine can be run in SW and a resultant cache entry stored in HW. >> Adding an ever changing set of rules + heuristics engine is a >> non-starter - at least that is the feedback I am getting from the HW >> engineers I have spoken with - mucho complexity + cost! > >I explained that IF you REQUIRE heuristics to run without state, then >you most likely need to implement them on hardware if you need high >speeds. I didn't mean to say anybody should try that, because I think >it is cheaper to do it by adding state. [Ken] This choice is vendor/device/architecture dependent and one approach may not fit all models. > >I think doing heuristics on the software is completely ok and doable, >for even very high speeds, when you do it in the smart way, i.e. use >state. I would expect following implementations to be usable: > >1) Keep state of the SPI information, doing slowpath heuristics on SW, > and doing fastpath part on HW (any speed). > >2) Keep state of the SPI information, doing slowpath heuristics on SW, > and doing fastpath part on SW (most likely up to 1 GBit/s). > >If you insist on not using state, then you can most likely do full >slowpath and fastpath on SW up to 100MBit/s speeds, and I do not >really see any point of doing any hardware version as making versions >1 or 2 above make much more sense. [Ken] If you are implementing all (or even part of the solution) in software, then I agree that this will not scale beyond a few 100Mbps - hence a HW approach is needed to support larger bandwidths. So, it depends on your HW architecture, what services are being supported by the device and the perceived cost/complexity/value in adding support for additional capabilities (e.g. Heuristics Vs. WESP). > >If you really require very high new connection rate, i.e. for example >you have 10Gbit/s link and it consists fully at IKEv2 creation (4 >packets), TCP session creation (3 packets), 2 data packets, TCP >session finish (4 packets), IKEv2 SA delete (2 packets), i.e. each >IPsec SA only contains one TCP session, which only exchange one data >packet. This means there is 15 packets in total 8 in one direction 7 >in other. IKE packets around 236 + 236 + 208 + 208 (with minimal >packet sizes for AES-SHA1, 1024 bit MODP, pre shared key) and 100 >bytes for IKEv2 deletes, TCP SYN/FIN packets are 40 bytes, and data >packets 40+64 bytes of data. So in total that means 1576 bytes and >using ethernet framing that makes 2146 octets -> 17168 bits. > >Using 10Gbit/s link that means we can do 582479 such exchanges per >second. For software implementation using 2GHz CPU that gives about >3400 cycles for doing the heuristics for the packet. That should be >plenty for doing heuristics, as they do not really have any loops or >other complicated operations. The one packet verification is around 10 >loads from packet, and around 15-20 compares, and we might need to do >that 6 times (for differet ICV/IV lengths), so in total we have at >about max 60 loads and 90-120 compares plus some basic arithmetics. > >I would expect that 2GHz CPU should keep up to that speed. 2GHz CPU >cannot keep up to the 10GBit/s line speed or do routing lookups for >that speeds, but if routing and non-heuristics packets are processed >by other hardware, one cpu should take care of the worst case >heuristics. [Ken] Are you saying that a 2GHz CPU is needed to run a heuristics engine? If so, then the question begs - is an intermediate device vendor willing to allocate a whole CPU for this task, or would this be better utilized for processing the packet payloads? If we can do this in a deterministic manner in HW, then the CPU cycles can be 'recovered' and better utilized for other tasks. > >So even at 10Gbit/s line speeds I do not think you need hardware >implementation of the slowpath heuristics part. > >> [Ken] There will always be a migration path, as well as exception >> cases. It is much easier to add a static rule for a fixed printer, >> then to have dynamic rules to allowing encrypted data to pass >> through the network. Additionally, some of the legacy devices may >> not even support a secure connection, so the traffic will be in the >> clear anyway. > >All of the traffic is in the clear, as we are talking about ESP-NULL >here. [Ken] By 'in the clear', I meant non-IPsec/ESP (traditional clear text) traffic; By encrypted, I meant 'wrapped in ESP' - i.e. ESP-NULL traffic - apologies for any confusion. > >My draft offers even simplier solution if you are accepting that kind >of solutions. It is mandated by policy option, then you do not need to >run heuristics at all, you simply assume all packets are ESP-NULL, as >that is mandated by policy, and those exception cases where this is >not true, you handle by adding rules... [Ken] I agree with this for 'fixed' devices such as printers, where it can have a well defined/known IP and there can be an 'exception rule' to accommodate these devices (e.g. allow traffic to/from this IP, irrespective of traffic type). Obviously these types of rules cannot be employed for other devices containing dynamic addresses. > >> E.g. How many printers support IPsec today? > >Not sure, but I do know there are such out there, and even more will >be (at least kyocera has announced their printers supporting IPsec and >IPv6 http://www.fishers- >boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_C >ombine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm). > [Ken] Thanks - this is good to know and I was not aware of it. >> If they need to support this in the future, then it is just as easy >> for them to support WESP, instead of ESP-NULL... > >Might be but for PCs you normally do this by updating the operating >system, how often have you updated the OS of your printer? And note >that they already support ESP-NULL and with heuristics they do not >need to update anything. With WESP they need to update their software. [Ken] Again, thanks - I was not aware that printers already support ESP-NULL. My comment was specifically for these devices that do not support ANY IPsec and future iterations can support the appropriate protocol, as needed. Having said that, as you indicated above, these type of devices are more amenable to exception rules, as they are fixed function and can have fixed addresses and are typically not expected to be the source / destination of threats, so in these cases, static rules will work just fine. > >Most of those vendors do not have their own IPsec, but it might either >come with the embedded operating system or it might be OEM toolkit, >which requires them to get new version of that, and new features >usually only comes with new versions (i.e. they are not part of the >bug fixes provided for old versions), thus they would need to update >to newer version of operating system or toolkit. > >As we do make IPsec OEM toolkit I can say that our customers have been >very reluctant to update to latest versions after they get their >pruducts out. there are still customers using 4 years old version. >Some of them are luckily now looking for updating to latest versions >for new products. I do not expect them to ever update their old >devices for new versions. > >So if we make WESP it will come out most likely during 2010 (and we >most likely do not make it unless there is customer demand for it (or >for heuristics), which mean that it might get pushed forward by year >or two), which will mean that some of our customers might delay up to >2015 before they update to that version, and after that it takes year >or so before they get their devices out. [Ken] Again, if we are talking about 'fixed function/fixed OS' devices, then these are static in nature and can be catered for as exceptions. IT departments are not too concerned with running Intrusion detection algorithms on data going to a printer, although it may end up being the norm at some time in the future. > >> [Ken] I think we need to consider all these issues in determining if >> a heuristics solution will work and scale under ALL circumstances. > >I do not think heuristics need to work in ALL circumstances. I think >it needs to work in the circumstances we are aiming for, and by >charter that is "an intermediary device, such as a firewall or >intrusion detection system". [Ken] I think we need to consider ALL devices that currently operate within the network and perform any data examination. A Firewall and an IDS are but two examples of such devices. > >Do you really consider stateless versions of those intermediary >devices something that will be common in the future? [Ken] No - I think they are common today! > >> By contrast, WESP does not have any of these issues (bar adoption), >> as it is being designed for efficiency, cost effectiveness and >> scalability. > >The adoptation is big issue there. > >As my draft says even if we go for WESP, I think the intermediary >device vendors still want to have some solution they can use now, thus >they will still need to implement heuristics. [Ken] Perhaps there is a migration path consideration, where heuristics can offer interim benefits until a more deterministic solution is adopted. Adoption of either / both / neither will be ultimately based on numerous factors, including value, customer demand, etc. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
