Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Bhatia, Manav (Manav) writes: > > You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility > > is needed. > > One might want to filter OSPFv3 packets coming from outside the domain. It is much better to do that check on the OSPFv3 receiver end where the packet is actually authenticated by ESP-NULL, and which has much better knowledge who is authorized to send what. I do not know OSPFv3 that well, so I do not know how you tell which packets are coiming outside of domain (as IP-addresses are not authenticated in ESP-NULL, so those cannot be checked), so I cannot really tell whether that check is doable or not. So what are the exact checks you are doing and where inside the OSFPv3 packet content are those fields, and what do they gain compared of doing the same checks on the final OSPFv3 receiver? > Then when you're the end node, you might want to prioritize some > OSPF packets over the others. I understand that the latter is an > implementation specific issue, but it helps if the underlying > protocol is amenable for deep inspection. End node already has all ESP-NULL related information, there is no need for ESP-NULL visibility there. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
> > > Yes, but I do not really think people are going to solve > those using > > > ESP-NULL. I think they must move to encrypted ESP to provide > > > confidentiality also, and that makes the need for > ESP-NULL visibility > > > even less. > > > > I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors > > will implement ESP (besides the problem of AH being NAT unfriendly). > > All applications (OSPFv3, RIPng, etc), and there are many, which > > don't care about confidentiality, but are only concerned with > > authentication and integrity assurance, will continue using > > ESP-NULL. > > > > Thus there is a need for ESP-NULL visibility. > > What kind of deep inspection you are doing on the OSPFv3 and RIPng in > the middle boxes? I.e. why does middle boxes need to know anything > about the actual data contents of those protocols? > > You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility > is needed. One might want to filter OSPFv3 packets coming from outside the domain. Then when you're the end node, you might want to prioritize some OSPF packets over the others. I understand that the latter is an implementation specific issue, but it helps if the underlying protocol is amenable for deep inspection. Cheers, Manav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Bhatia, Manav (Manav) writes: > > > > > 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. > > > > Yes, but I do not really think people are going to solve those using > > ESP-NULL. I think they must move to encrypted ESP to provide > > confidentiality also, and that makes the need for ESP-NULL visibility > > even less. > > I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors > will implement ESP (besides the problem of AH being NAT unfriendly). > All applications (OSPFv3, RIPng, etc), and there are many, which > don't care about confidentiality, but are only concerned with > authentication and integrity assurance, will continue using > ESP-NULL. > > Thus there is a need for ESP-NULL visibility. What kind of deep inspection you are doing on the OSPFv3 and RIPng in the middle boxes? I.e. why does middle boxes need to know anything about the actual data contents of those protocols? You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility is needed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
> > > 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. > > Yes, but I do not really think people are going to solve those using > ESP-NULL. I think they must move to encrypted ESP to provide > confidentiality also, and that makes the need for ESP-NULL visibility > even less. I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors will implement ESP (besides the problem of AH being NAT unfriendly). All applications (OSPFv3, RIPng, etc), and there are many, which don't care about confidentiality, but are only concerned with authentication and integrity assurance, will continue using ESP-NULL. Thus there is a need for ESP-NULL visibility. Cheers, Manav > > For example most of the insider information (insider trading, leaking > trade secrets, espionage) problems cannot be solved by using ESP-NULL. > > > [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. > > This I agree and I have even tried to bring this up in my draft (see > last paragraph in the introduction section). > -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: > >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. Note that you cannot do QoS without the co-operation of the sending IPsec site. The sending IPsec node needs to put packets getting separate QoS handling to separate SAs as otherwise the receiving IPsec node will drop packets if they get out of the replay window. Because of this there is no need to inspect the content of the ESP packet, QoS must be done based on the IPsec SA, i.e. IP-addresses and SPI number. So for QoS there is no need to inspect the data inside the ESP-NULL packet, as you cannot give different handling to different packets, as if you do so, then those ESP-NULL packets getting slower path might get dropped by the receiving IPsec node, as those packets getting faster path have already moved replay window so that those slower packets do not fit in to it anymore. > [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. My guess is that regardless what we do, at least some middle box vendors will implement heuristics in their high-end boxes, and after one vendor supports it, others need to support it too to be able to offer similar features than their competitors do. After a while even more low-end devices will support it and soon most middle boxes do support it. After that the requirements for supporting WESP will drop, as middle-boxes work without it, so general support for it will stay even lower. But that is just my guess... > [Ken] Why is DoS not a big problem, especially if we generate a new > DoS opportunity on a new 'cache' in the network device? DoS opportunities is a problem, but I do not think SPI cache will create that much new opportunities. I.e. I claim that the SPI cache can be implemented in such way that it does not offer any major DoS opportunity. > 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. Yes, but I do not really think people are going to solve those using ESP-NULL. I think they must move to encrypted ESP to provide confidentiality also, and that makes the need for ESP-NULL visibility even less. For example most of the insider information (insider trading, leaking trade secrets, espionage) problems cannot be solved by using ESP-NULL. > [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. This I agree and I have even tried to bring this up in my draft (see last paragraph in the introduction section). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: > [Ken] In some cases, the certainty must be 100%, otherwise there is > no control. E.g. A new exploit has just been published for certain > types of traffic - published vulnerability where a virus/worm can > exploit a 'buffer overrun/stack overflow' condition for a given > piece of software providing a given service, which subsequently > allows a hijacker to take control of the machine/server. That > service MUST be shut down to ensure that the vulnerability cannot be > exploited and spread. This may or may not result in shut down of the > server hosting the service, as you may want to allow remote > patching, etc. Easiest way to do this is to block the port over > which the vulnerability is being exploited. Which does not help if you allow any encrypted ESP traffic to the host, as the attacker will then just use encrypted ESP to make the attack. On the other hand if you do not allow any encrypted ESP packets, you KNOW that all packets are ESP-NULL, which makes the packet checks much easier even for stateless devices. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
>> [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 >append
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
>At 2:33 PM -0700 2/10/09, Grewal, Ken wrote: >>Stateless firewalls are commonly employed for efficiency and as a crude >method for cutting off access to certain services - these are useful for >basic access control in cost effective, high bandwidth, network scenarios. >E.g. Corporations may not want to allow various P2P protocols, discovery of >resources, access to certain services (especially if using UDP as the >underlying protocol), remote access/management to certain resources from >outside well established network boundaries, etc., etc.. There are >thousands of well defined ports providing different services from legacy, >experimental, to the 'latest, greatest, service of the day' - and someone >just found an exploit for and there is no fix available! How do you ensure >that your network doesn't get inundated with unwanted traffic or exploited? >Block that port!! >> >>Stateless firewalls can and do provide the fundamental building blocks for >basic access control. In these scenarios, the need to differentiate between >encrypted / NULL ESP traffic is required to enforce these policies, without >the need or burden of keeping state on 'connections' or 'security >sessions'. > >(Not wearing any hat) [Ken] Wearing a basketball hat - 'go blazers!' :-) > >What level of assuredness do stateless firewalls need? That is, a stateless >firewall can easily look inside what it is passing to get a simple guess >about what is in the packet; this happens all the time on port 80. There >are well known but imperfect heuristics for inspecting content on port 80; >some of those could be used on ESP as well. > >People commenting on this thread should state what level of certainty they >think the middleboxes need to have, in addition to saying what properties >they think those middleboxes have (such as ability to retain state, how >much state, how long, and so on). [Ken] In some cases, the certainty must be 100%, otherwise there is no control. E.g. A new exploit has just been published for certain types of traffic - published vulnerability where a virus/worm can exploit a 'buffer overrun/stack overflow' condition for a given piece of software providing a given service, which subsequently allows a hijacker to take control of the machine/server. That service MUST be shut down to ensure that the vulnerability cannot be exploited and spread. This may or may not result in shut down of the server hosting the service, as you may want to allow remote patching, etc. Easiest way to do this is to block the port over which the vulnerability is being exploited. Just one example and I am sure there are numerous others... ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
At 2:33 PM -0700 2/10/09, Grewal, Ken wrote: >Stateless firewalls are commonly employed for efficiency and as a crude method >for cutting off access to certain services - these are useful for basic access >control in cost effective, high bandwidth, network scenarios. E.g. >Corporations may not want to allow various P2P protocols, discovery of >resources, access to certain services (especially if using UDP as the >underlying protocol), remote access/management to certain resources from >outside well established network boundaries, etc., etc.. There are thousands >of well defined ports providing different services from legacy, experimental, >to the 'latest, greatest, service of the day' - and someone just found an >exploit for and there is no fix available! How do you ensure that your network >doesn't get inundated with unwanted traffic or exploited? Block that port!! > >Stateless firewalls can and do provide the fundamental building blocks for >basic access control. In these scenarios, the need to differentiate between >encrypted / NULL ESP traffic is required to enforce these policies, without >the need or burden of keeping state on 'connections' or 'security sessions'. (Not wearing any hat) What level of assuredness do stateless firewalls need? That is, a stateless firewall can easily look inside what it is passing to get a simple guess about what is in the packet; this happens all the time on port 80. There are well known but imperfect heuristics for inspecting content on port 80; some of those could be used on ESP as well. People commenting on this thread should state what level of certainty they think the middleboxes need to have, in addition to saying what properties they think those middleboxes have (such as ability to retain state, how much state, how long, and so on). --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Stateless firewalls are commonly employed for efficiency and as a crude method for cutting off access to certain services - these are useful for basic access control in cost effective, high bandwidth, network scenarios. E.g. Corporations may not want to allow various P2P protocols, discovery of resources, access to certain services (especially if using UDP as the underlying protocol), remote access/management to certain resources from outside well established network boundaries, etc., etc.. There are thousands of well defined ports providing different services from legacy, experimental, to the 'latest, greatest, service of the day' - and someone just found an exploit for and there is no fix available! How do you ensure that your network doesn't get inundated with unwanted traffic or exploited? Block that port!! Stateless firewalls can and do provide the fundamental building blocks for basic access control. In these scenarios, the need to differentiate between encrypted / NULL ESP traffic is required to enforce these policies, without the need or burden of keeping state on 'connections' or 'security sessions'. Thanks, - Ken >-Original Message- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of >Yoav Nir >Sent: Tuesday, February 10, 2009 11:52 AM >To: gabriel montenegro; Tero Kivinen; Grewal, Ken >Cc: ipsec@ietf.org; Dragan Grebovich >Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > >gabriel montenegro wrote: > >>I'll just comment on one item below: >> >>> 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. >> >>Disagree completely. The charter item is a general one for intermediary >devices >>(some of which are and are expected to continue being stateless). >> >>The above was just an example. > >OK, so give us a counter-example. Why would a stateless device want to be >able to tell the difference between ESP-AES-CBC and ESP-NULL. What policy >is it trying to enforce? > > > > >Email secured by Check Point >___ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
gabriel montenegro wrote: >I'll just comment on one item below: > >> 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. > >Disagree completely. The charter item is a general one for intermediary devices >(some of which are and are expected to continue being stateless). > >The above was just an example. OK, so give us a counter-example. Why would a stateless device want to be able to tell the difference between ESP-AES-CBC and ESP-NULL. What policy is it trying to enforce? Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
I'll just comment on one item below: > 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. Disagree completely. The charter item is a general one for intermediary devices (some of which are and are expected to continue being stateless). The above was just an example. Gabriel - Original Message > From: Tero Kivinen > To: "Grewal, Ken" > Cc: "ipsec@ietf.org" ; Dragan Grebovich > Sent: Monday, February 9, 2009 6:19:54 AM > Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > > Grewal, Ken writes: > > [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. > > 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? > > 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? > > 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] 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. > > > 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. > > > 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. > > 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 s
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: > [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. 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? 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? 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] 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. > 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. > 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. 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). 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 al
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Gabriel, Since we are still in the midst of technical discussion, I am perfectly willing to wait a few more days and then directly ask Tero and Dan, as well as other supporters of the heuristics approach, for their opinion in the matter. I believe this would be more fruitful than interpreting the wording of their draft. In the meantime, I'd like to focus on this technical discussion and ensure that we've explored as many issues as we can. Thanks, Yaron > -Original Message- > From: gabriel montenegro [mailto:g_e_montene...@yahoo.com] > Sent: Saturday, February 07, 2009 1:53 > To: Paul Hoffman; Yaron Sheffer; Dragan Grebovich; Yoav Nir; > ipsec@ietf.org > Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > > Thanks for the clarification. If I could ask for further clarification > here: is there much support > for the claim that heuristics is sufficient for ALL scenarios now and in > the future > (approach #2 as noted by the chairs below)? > > The reason I ask is that Tero/Dan themselves don't seem to espouse this > view. > At least that is what their draft says in the introduction: > >To make sure that any solution does not break in the >future it would be best if such heuristics are documented, i.e. we >need to publish an RFC for what to do now even when there might be a >new protocol coming in the future that will solve the same problem >better. > This talks about co-existence of heuristics with another approach > (presumably deterministic), > which is the approach #1 as noted by the chairs below. > > I agree with approach #1, of course, so was glad to see that in Tero's > draft, but > would like to be corrected if somehow I'm misreading the above text. > > thanks, > > Gabriel > > > > - Original Message > > From: Paul Hoffman > > To: Yaron Sheffer ; gabriel montenegro > ; Dragan Grebovich ; Yoav Nir > ; "ipsec@ietf.org" > > Sent: Thursday, February 5, 2009 5:00:20 AM > > Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > > > > At 9:52 AM +0200 2/5/09, Yaron Sheffer wrote: > > >Hi Gabriel, > > > > > >This thread is precisely the discussion that Paul mentions. > > > > > >The two alternatives I see on the table right now (Paul might have > different > > opinions) are: > > > > > >- Publish a modified/wrapped ESP as Standards Track, and > heuristics as > > an extra Informational. > > >- Decide that heuristics are a sufficient solution for the > problem, > > and publish it as the only ipsecme work item related to this charter > item. > > > > > >Paul and I would like to see more discussion and hopefully WG consensus > being > > formed, now that we have a real heuristics I-D for everyone to analyze. > > > > I fully agree with Yaron on all counts. If the WG thinks that heuristics > is > > sufficient, we should not publish a protocol change. If the WG doesn't > think > > heuristics are sufficient, the authors can publish it as an individual > > submission or an independent submission. > > > > --Paul Hoffman, Director > > --VPN Consortium > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Additional comment below... ...Snip... >> Cache eviction - how will this work? >> We can keep adding SAs (based on heuristics), but how do we decide >> when a given SA is no longer needed? This compounds the issues with >> keeping state, as in the best case, cache eviction will likely be >> policy based. How is the policy determined and how do we >> differentiate between short and long lived SAs? As the SA cache will >> be of a finite size, this WILL lead to a cache thrash (add SA, evict >> SA, ...), causing further resource consumption. > >This is actually quite good point, and it is also implementation >detail that do affect the performance. > >How this can be solved depends quite heavily on the environment where >heuristics is used. If we are doing firewall that already keeps state >of all TCP/UDP flows, then it would be natural to weakly bind IPsec >SAs and TCP/UDP flows inside together. For example keep in track when >there is no more TCP/UDP flows using the IPsec SA (i.e. all the >TCP/UDP flows which used this SA before, have now been moved to new >IPsec SA), and after that you can most likely remove the IPsec SA >entry quite quickly. [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. > >Another, and probably more common implementation will be just some >simple LRU based mechanisms to reuse old IPsec SA entries. This kind >of things are usually already done for the UDP protocols. [Ken] These require timestamps (or other ordering / metric based approaches) and monitoring to ensure the cache is up to date. Furthermore, it may also provide opportunities for adversaries to use periodic replays to provide cache thrash and associated overhead in re-executing heuristics engines. 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... > >> How about dynamic route changes for already established SAs? The >> same problem will exist as the Monday morning problem, but without >> the diffie-hellman overhead. Because we are caching state on one >> device, a change in route where the packets take a different path >> will force the new device to 'relearn' all the cached info. > >Yes, but heuristics is still fast operation, thus that should not be >problem. Bigger problem usually is that the deep inspection state is >lost too... [Ken] But not for stateless devices, which will carry the 'resync/Monday morning problem' each time. > >> High availability is another one to consider, especially during >> maintenance periods. One device is powered down and a backup device >> takes over. This is similar to route changes in principle, where the >> backup device will need to relearn all the state. > >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. > >> Agree, but the heuristics engine may be heavily used as VOIP becomes >> prevalent, especially within the Enterprise. Lots and lots of UDP >> traffic that is short lived, which ties back to earlier points on >> cache maintenance and frequency of exercising the heuristics engine. > >If we know anything about the contents of the UDP packet (i.e. >recognize that it is VOIP traffic), we can most likely do heuristics >based on the single packet. Even if there is only 32 bits of the known >data in the packet (lets say version number and magic cookie or >similar), then usually that is already enough for detecting the >parameters and the probability that random ESP-encrypted packet has >same content is less than 0.00024% (1/(2^32) * 100%). > >So if VOIP traffic is heavily used then the heuristics most likely >will have special protocol detection code for it. [Ken] The point being that this traffic may be short lived, smaller packet, hence more packet per bandwidth, which will exercise the heuristics engine / cache issues much more then, say long lived TCP sessions (which are rare). > >> 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 implement
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich writes: > I looked for some traffic stats in a real, large enterprise network and > I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic. The > stats were measured on multiple places in the network, and multiple > samples were taken over the past 6 weeks. Also, there is a slow but > consistent growth of UDP traffic over the past couple of years, pointing > to a long term trend. Can you provide information what kind of UDP traffic that was? I would except DNS, and different voip protocols, but what else? > IMHO heuristics would require more frequent inspections than just the > first few packets in a flow, and would require more heuristics rules on > a per app basis, instead of relying on fixed TCP immutable fields. For heuristics it is enough to do just to inspect first few packets. After we have found out the parameters, then we just use them. The deep inspection that is using the results of the heuristics (i.e. to find the actual protocol data) will of course need to inspect every packet. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
I looked for some traffic stats in a real, large enterprise network and I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic. The stats were measured on multiple places in the network, and multiple samples were taken over the past 6 weeks. Also, there is a slow but consistent growth of UDP traffic over the past couple of years, pointing to a long term trend. IMHO heuristics would require more frequent inspections than just the first few packets in a flow, and would require more heuristics rules on a per app basis, instead of relying on fixed TCP immutable fields. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
By a 'colluding peer', I meant that both sides need to negotiate the same policy (e.g. this is sensitive data, so only allow encrypted traffic or vice versa). I think this boils down to how tight the admin policy is and also whether it is desirable to allow encrypted/clear policies for different services to the same server/cluster, which could result in the unintentionally attack I described below. Thanks, - Ken From: Yaron Sheffer [mailto:yar...@checkpoint.com] Sent: Thursday, February 05, 2009 12:45 AM To: Grewal, Ken; Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Hi Ken, Yoav, I agree with Ken that the policy needs not be black and white, but for a different reason. Some people will treat deep packet inspection by middleboxes as an optional service: you want it for most traffic, but some traffic is too sensitive and you choose to prioritize confidentiality over malware protection. This model is definitely susceptible to attacks by infected endpoints that can control the IPsec stack, and e.g. attack a server using encrypted traffic. You don't really need a "colluding" peer - most peers will probably accept either an ESP-null or an ESP-encrypted proposal. But admins may be willing to take this risk. Thanks, Yaron From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Grewal, Ken Sent: Wednesday, February 04, 2009 20:25 To: Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Quote ... "Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns will be mixed in reality (encrypted Vs. clear) and policy will dictate how a given traffic stream in inspected and if it is opaque then take the associated action (drop / bypass / apply QOS rules / send a different path in the network / etc...). e.g. There may be a secure channel to transfer highly sensitive data (e.g. payroll, company secrets, etc.) which should be encrypted and it may be undesirable to categorize this under a general rule - this is a simple extension of the firewall function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may also be possible unintentionally. E.g. Connection to a server (cluster / farm) to gain access to a 'normal' service uses ESP-NULL and then at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same client IP (but may be different client due to NAT), same SPI - SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device has a cached rule (based on the previous connection) indicating the traffic is clear, it will lead to falsely inferring the contents of the payload and undesirable results. This goes to my point on cache eviction policy for heuristics based intermediate devices, as highlighted in a separate thread. Reuse of the same 'tuple' with different traffic characteristics may be infrequent, but still plausible. I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the policy indicates all traffic is ESP-NULL. Thanks, - Ken From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
At 9:52 AM +0200 2/5/09, Yaron Sheffer wrote: >Hi Gabriel, > >This thread is precisely the discussion that Paul mentions. > >The two alternatives I see on the table right now (Paul might have different >opinions) are: > >- Publish a modified/wrapped ESP as Standards Track, and heuristics >as an extra Informational. >- Decide that heuristics are a sufficient solution for the problem, >and publish it as the only ipsecme work item related to this charter item. > >Paul and I would like to see more discussion and hopefully WG consensus being >formed, now that we have a real heuristics I-D for everyone to analyze. I fully agree with Yaron on all counts. If the WG thinks that heuristics is sufficient, we should not publish a protocol change. If the WG doesn't think heuristics are sufficient, the authors can publish it as an individual submission or an independent submission. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: > The 'bait and switch' attack where a connection uses ESP-NULL and > then at a later stage uses ESP-Encrypted may also be possible > unintentionally. E.g. Connection to a server (cluster / farm) to > gain access to a 'normal' service uses ESP-NULL and then at a later > stage, where the previous connection was torn down and a new one > built, the connection is obtaining some sensitive data and is now > using ESP-Encrypted. On the outside, the connection attributes look > the same (same server IP, same client IP (but may be different > client due to NAT), same SPI - SPIs can be reused for new > connections to preserve fast lookups algorithms at recipients), but > underneath the connection is to access a different resource (may be > using a different port or service above the IP layer). If the > intermediate device has a cached rule (based on the previous > connection) indicating the traffic is clear, it will lead to falsely > inferring the contents of the payload and undesirable results. This was covered in the draft section 7, where it said that if deep inspection engine suddenly starts getting lots of garbage then it should rerun the heuristics. > I agree with Yoav that this attack may also be possible > intentionally between two colluding parties, where the policy > indicates all traffic is ESP-NULL. It is much easier to use ESP-NULL wrapped TLS, or SSH in those cases. If both ends want to use encryption then the middle boxes cannot really prevent it very easily. If TLS and SSH and blocked then use IP(sec) over DNS, or IP(sec) over HTTP, and if even those fail then use IP(sec) over mail :-) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: > Cache eviction - how will this work? > We can keep adding SAs (based on heuristics), but how do we decide > when a given SA is no longer needed? This compounds the issues with > keeping state, as in the best case, cache eviction will likely be > policy based. How is the policy determined and how do we > differentiate between short and long lived SAs? As the SA cache will > be of a finite size, this WILL lead to a cache thrash (add SA, evict > SA, ...), causing further resource consumption. This is actually quite good point, and it is also implementation detail that do affect the performance. How this can be solved depends quite heavily on the environment where heuristics is used. If we are doing firewall that already keeps state of all TCP/UDP flows, then it would be natural to weakly bind IPsec SAs and TCP/UDP flows inside together. For example keep in track when there is no more TCP/UDP flows using the IPsec SA (i.e. all the TCP/UDP flows which used this SA before, have now been moved to new IPsec SA), and after that you can most likely remove the IPsec SA entry quite quickly. Another, and probably more common implementation will be just some simple LRU based mechanisms to reuse old IPsec SA entries. This kind of things are usually already done for the UDP protocols. > How about dynamic route changes for already established SAs? The > same problem will exist as the Monday morning problem, but without > the diffie-hellman overhead. Because we are caching state on one > device, a change in route where the packets take a different path > will force the new device to 'relearn' all the cached info. Yes, but heuristics is still fast operation, thus that should not be problem. Bigger problem usually is that the deep inspection state is lost too... > High availability is another one to consider, especially during > maintenance periods. One device is powered down and a backup device > takes over. This is similar to route changes in principle, where the > backup device will need to relearn all the state. 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. > Agree, but the heuristics engine may be heavily used as VOIP becomes > prevalent, especially within the Enterprise. Lots and lots of UDP > traffic that is short lived, which ties back to earlier points on > cache maintenance and frequency of exercising the heuristics engine. If we know anything about the contents of the UDP packet (i.e. recognize that it is VOIP traffic), we can most likely do heuristics based on the single packet. Even if there is only 32 bits of the known data in the packet (lets say version number and magic cookie or similar), then usually that is already enough for detecting the parameters and the probability that random ESP-encrypted packet has same content is less than 0.00024% (1/(2^32) * 100%). So if VOIP traffic is heavily used then the heuristics most likely will have special protocol detection code for it. > 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. Of course if you are talking about very low cost appliances, then they will not have modern CPUs, but on the other hand people do not normally expect them to keep up with 1GBit/s speeds... > The speed of deployment may or may not be true. If the stars are > aligned, then it could be deployed within one or two refresh cycles, > which is about the same for heuristics in intermediaries devices. > After all, only a handful of vendors own a large percentage of the > market for OS / intermediary devices. Adoption is obviously based on > customer pull/perceived usefulness. The difference is that heuristics can be deployed within one or two refresh cycles of the intermediate devices after customers start to ask for it. Modified ESP can be deployed within one or two refresh cycles of the slowest vendor whose devices are used in the network. Meaning that if the printer vendor used in the network does not update their IPsec to support that modified ESP, then that modified ESP cannot be used by intermediate devices. > >Heuristics can also be implemented regardless of IKEv1 or IKEv2. > >Modifying the
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Ken, Yoav, I agree with Ken that the policy needs not be black and white, but for a different reason. Some people will treat deep packet inspection by middleboxes as an optional service: you want it for most traffic, but some traffic is too sensitive and you choose to prioritize confidentiality over malware protection. This model is definitely susceptible to attacks by infected endpoints that can control the IPsec stack, and e.g. attack a server using encrypted traffic. You don't really need a "colluding" peer - most peers will probably accept either an ESP-null or an ESP-encrypted proposal. But admins may be willing to take this risk. Thanks, Yaron From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Grewal, Ken Sent: Wednesday, February 04, 2009 20:25 To: Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Quote ... "Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns will be mixed in reality (encrypted Vs. clear) and policy will dictate how a given traffic stream in inspected and if it is opaque then take the associated action (drop / bypass / apply QOS rules / send a different path in the network / etc...). e.g. There may be a secure channel to transfer highly sensitive data (e.g. payroll, company secrets, etc.) which should be encrypted and it may be undesirable to categorize this under a general rule - this is a simple extension of the firewall function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may also be possible unintentionally. E.g. Connection to a server (cluster / farm) to gain access to a 'normal' service uses ESP-NULL and then at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same client IP (but may be different client due to NAT), same SPI - SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device has a cached rule (based on the previous connection) indicating the traffic is clear, it will lead to falsely inferring the contents of the payload and undesirable results. This goes to my point on cache eviction policy for heuristics based intermediate devices, as highlighted in a separate thread. Reuse of the same 'tuple' with different traffic characteristics may be infrequent, but still plausible. I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the policy indicates all traffic is ESP-NULL. Thanks, - Ken From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for eac
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Gabriel, This thread is precisely the discussion that Paul mentions. The two alternatives I see on the table right now (Paul might have different opinions) are: - Publish a modified/wrapped ESP as Standards Track, and heuristics as an extra Informational. - Decide that heuristics are a sufficient solution for the problem, and publish it as the only ipsecme work item related to this charter item. Paul and I would like to see more discussion and hopefully WG consensus being formed, now that we have a real heuristics I-D for everyone to analyze. Thanks, Yaron From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of gabriel montenegro Sent: Thursday, February 05, 2009 9:38 To: Dragan Grebovich; Yoav Nir; ipsec@ietf.org; Paul Hoffman Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments I'd like to ask the chairs to comment further about something they (Paul) said during the virtual interim about Tero's heuristics draft. From the minutes: Paul said that we will discuss on the list before we decide which direction we will go What directions do you see possible? I can see the value in publishing it as an informational draft as a separate orthogonal effort to the deterministic approach. It's not that heuristics are undoable, but as this thread (and others before it) has borne: it is not a general solution applicable in all cases. From: Dragan Grebovich To: Yoav Nir ; ipsec@ietf.org Sent: Wednesday, February 4, 2009 11:24:20 AM Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Hi Yoav As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI. That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower). Who am I to tell a Checkpoint guy about both implementations? :-) I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache. Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow. I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. Also, DPI can be used for more than just AV or packet content snooping. It could be used for QoS to determine more granular traffic shaping and application-level routing. There is also LI/CALEA aspect but I will leave that alone for now. From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Wednesday, February 04, 2009 3:04 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions o
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
I'd like to ask the chairs to comment further about something they (Paul) said during the virtual interim about Tero's heuristics draft. From the minutes: Paul said that we will discuss on the list before we decide which direction we will go What directions do you see possible? I can see the value in publishing it as an informational draft as a separate orthogonal effort to the deterministic approach. It's not that heuristics are undoable, but as this thread (and others before it) has borne: it is not a general solution applicable in all cases. From: Dragan Grebovich To: Yoav Nir ; ipsec@ietf.org Sent: Wednesday, February 4, 2009 11:24:20 AM Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments draft-kivinen-ipsecme-esp-null-heuristics comments Hi Yoav As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI. That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower). Who am I to tell a Checkpoint guy about both implementations? :-) I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache. Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow. I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. Also, DPI can be used for more than just AV or packet content snooping. It could be used for QoS to determine more granular traffic shaping and application-level routing. There is also LI/CALEA aspect but I will leave that alone for now. From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Wednesday, February 04, 2009 3:04 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives.Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, a
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Yoav As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI. That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower). Who am I to tell a Checkpoint guy about both implementations? :-) I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache. Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow. I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements.. Also, DPI can be used for more than just AV or packet content snooping. It could be used for QoS to determine more granular traffic shaping and application-level routing. There is also LI/CALEA aspect but I will leave that alone for now. From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Wednesday, February 04, 2009 3:04 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular inspection 3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "at
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Quote ... "Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns will be mixed in reality (encrypted Vs. clear) and policy will dictate how a given traffic stream in inspected and if it is opaque then take the associated action (drop / bypass / apply QOS rules / send a different path in the network / etc...). e.g. There may be a secure channel to transfer highly sensitive data (e.g. payroll, company secrets, etc.) which should be encrypted and it may be undesirable to categorize this under a general rule - this is a simple extension of the firewall function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may also be possible unintentionally. E.g. Connection to a server (cluster / farm) to gain access to a 'normal' service uses ESP-NULL and then at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same client IP (but may be different client due to NAT), same SPI - SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device has a cached rule (based on the previous connection) indicating the traffic is clear, it will lead to falsely inferring the contents of the payload and undesirable results. This goes to my point on cache eviction policy for heuristics based intermediate devices, as highlighted in a separate thread. Reuse of the same 'tuple' with different traffic characteristics may be infrequent, but still plausible. I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the policy indicates all traffic is ESP-NULL. Thanks, - Ken From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device tha
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Some comments inline... Thanks, Ken >-Original Message- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of >Tero Kivinen >Sent: Tuesday, February 03, 2009 5:12 AM >To: Dragan Grebovich >Cc: ipsec@ietf.org >Subject: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments > >Dragan Grebovich writes: >> Hi Tero >> I reviewed your heuristics draft and I believe it is interesting and >> doable, however: >> >> 1) I believe the actual implementation would require more code than >> current front-end hardware allows. The hardware we work with have a >> limited space for that much heuristics code. Our preference is to find >> a quick direct match (in a few instructions max). We would have to >> respin hardware to allow your heuristics implementation. This might not >> be implementable today, as hardware respins are costly and take >> relatively long. > >In normal cases, I would expect that heuristics are not run on the >hardware, only the SPI cache is run there (i.e. the Appendix A.1 part >of the operations). This kind of processing is already run on the >firewalls, deep inspection devices and so on, usually per TCP flow >basis. Adding that to be run on per IPsec SA basis should be very >small addition to the front-end hardware. > >Are you saying that even that is too complicated? Complexity is one thing, but there is a cost vector to consider too and the answer may be different based on the device being targeted. Some devices may be capable of doing the heuristics processing in SW as an exception case, whereas other devices (e.g. requiring high bandwidth DPI) need to do this in HW to maintain line rates. >From a cost perspective, If a device is stateless in nature (e.g. traffic >monitoring/logging for auditing purposes), then that device will now need to >be stateful to maintain all these (potentially hundreds of thousands) or >3-tuples as state, which may not be practical. Cost also reflects expensive SRAM to store these cached policies, which may be pennies, but in a low end NIC can be a cost-inhibitive to implement. > >> 2) On low-end products, e.g. Access (aka Edge) it is unlikely that >> today's and even tomorrow's implementations will have stateful DPI >> implemented; these devices have low target COGS and usually do not have >> simple packet filters and stateless firewalls and signature-based DPI >> and IDS/IPS. It is unlikely that this would be the potential >> implementation target for heuristics, as the cost/price would go up. > >If they do not have "simple packet filters and stateless firewalls and >signature-based DPI and IDS/IPS", then they do not need heuristics at >all, as there is no need to differentiate the ESP vs ESP-NULL. > >Heuristics solution do not require any changes to those low-end >product. On the other hand the new protocol number for ESP most likely >will require changes to those devices, as they need to be sure to pass >that protocol number also. Any addition of a new protocol will require changes to any device that does not support that protocol, so this argument is not unique to WESP, but applicable to all new protocols - e.g. how would these devices act when seeing the recently introduced HIP protocol or UDP-Lite? If we use this argument that a new protocol addition will impact legacy devices, we should not be allocating ANY new protocols - full stop! Also see previous argument for low end devices above. > >> 3) High-end products, e.g. Data Center front-ends, would allow a >> heuristics implementation; it may have a stateful firewall and/or >> IDS/IPS and other DPI capabilities, however this class of devices is >> migrating towards virtualized platforms (major vendors are moving in >> that direction), and they would be terminating tens or even hundreds of >> thousands of SAs. > >Heuristics are not needed on the devices which are terminating IPsec >SAs. Devices terminating IPsec SAs already know all IPsec SA state, >thus they do not need heuristics. > >Heuristics is only needed on devices which do all the following: > >1) Do want to some kind of deep inspection on the ESP-NULL packets. > >2) Are on the path of the IPsec flow, but not participating in the > IPsec SA (i.e. is not a node where IPsec SA terminates). > Agreed - any device terminating the SA has all the info it needs already. >Note, that usually one IPsec SA has tens or hundreds of the TCP or UDP >flows inside, thus for each entry added to the SPI cache, the TCP or >UDP caches require much more. This is typically true for VPN/Tunneling, but not true for transport mode, E2E solutions, where an IPsec SA will be as granular as the traffic it is carrying
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular inspection 3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, February 03, 2009 5:16 AM To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Hi Tero I reviewed your heuristics draft and I believe it is interesting and doable, however: 1) I believe the actual implementation would require more code than current front-end hardware allows. The hardware we work with have a limited space for that much heuristics code. Our preference is to find a quick direct match (in a few instructions max). We would have to respin hardware to allow your heuristics implementation. This might not be implementable today, as hardware respins are costly and take relatively long. 2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's and even tomorrow's implementations will have stateful DPI implemented; these devices have low target COGS and usually do not have simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS. It is unlikely that this would be the potential implementation target for heuristics, as the cost/price would go up. 3) High-end products, e.g. Data Center front-ends, would allow a heuristics implementation; it may have a stateful firewall and/or IDS/IPS and other DPI capabilities, however this class of devices is migrating towards virtualized platforms (major vendors are moving in that direction), and they would be terminating tens or even hundreds of thousands of SAs. 4) Even if these high-end devices have implementations running on multicores, everyone is struggling to provide low latency and high throughput, squeezing the last possible bit through of the pipe. Keeping state until one finds that there is a match or not may introduce unwanted latency and create large memory consumption (multiply everything by e.g. 100K Sas) which we may not be able to afford. 5) On these High-end appliances, there is a definite need for load-balancing between flows. That means the amount of the required memory space will be at least 2x or 3x more, and also there is need for additional CPU and I/O overhead to maintain two or more loanbalancers in sync. 6) Another problem I see is that more traffic today is carried on UDP, and those are inherently difficult to track as "flows". One must keep a significant portion of traffic to determine ESP vs. ESP-NULL. Years ago it was rare and mostly used for implementations such as SNMP, but these days new applications ar ecoming out (e.g. Bittorrent-over-UDP). SIP-over-UDP is another such implementation that may cause problems, if heuristics are implemented in intermediate devices. 7) There will be stateful appliances in the future, but stateless devices will remain in the future; these will not be able
[IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich writes: > Hi Tero > I reviewed your heuristics draft and I believe it is interesting and > doable, however: > > 1) I believe the actual implementation would require more code than > current front-end hardware allows. The hardware we work with have a > limited space for that much heuristics code. Our preference is to find > a quick direct match (in a few instructions max). We would have to > respin hardware to allow your heuristics implementation. This might not > be implementable today, as hardware respins are costly and take > relatively long. In normal cases, I would expect that heuristics are not run on the hardware, only the SPI cache is run there (i.e. the Appendix A.1 part of the operations). This kind of processing is already run on the firewalls, deep inspection devices and so on, usually per TCP flow basis. Adding that to be run on per IPsec SA basis should be very small addition to the front-end hardware. Are you saying that even that is too complicated? > 2) On low-end products, e.g. Access (aka Edge) it is unlikely that > today's and even tomorrow's implementations will have stateful DPI > implemented; these devices have low target COGS and usually do not have > simple packet filters and stateless firewalls and signature-based DPI > and IDS/IPS. It is unlikely that this would be the potential > implementation target for heuristics, as the cost/price would go up. If they do not have "simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS", then they do not need heuristics at all, as there is no need to differentiate the ESP vs ESP-NULL. Heuristics solution do not require any changes to those low-end product. On the other hand the new protocol number for ESP most likely will require changes to those devices, as they need to be sure to pass that protocol number also. > 3) High-end products, e.g. Data Center front-ends, would allow a > heuristics implementation; it may have a stateful firewall and/or > IDS/IPS and other DPI capabilities, however this class of devices is > migrating towards virtualized platforms (major vendors are moving in > that direction), and they would be terminating tens or even hundreds of > thousands of SAs. Heuristics are not needed on the devices which are terminating IPsec SAs. Devices terminating IPsec SAs already know all IPsec SA state, thus they do not need heuristics. Heuristics is only needed on devices which do all the following: 1) Do want to some kind of deep inspection on the ESP-NULL packets. 2) Are on the path of the IPsec flow, but not participating in the IPsec SA (i.e. is not a node where IPsec SA terminates). Note, that usually one IPsec SA has tens or hundreds of the TCP or UDP flows inside, thus for each entry added to the SPI cache, the TCP or UDP caches require much more. This means that high-end producsts need to have memory for storing hundreds of thousands or even millions of TCP/UDP flows anyways, and adding some for IPsec SA flows does not significantly increase the number (in the worst case scenario, where each IPsec SA has exactly one TCP flow inside, it might double the number of flows needed to be stored). > 4) Even if these high-end devices have implementations running on > multicores, everyone is struggling to provide low latency and high > throughput, squeezing the last possible bit through of the pipe. > Keeping state until one finds that there is a match or not may introduce > unwanted latency and create large memory consumption (multiply > everything by e.g. 100K Sas) which we may not be able to afford. During normal operation there is no increased latency or slow throughput, as the used IPsec SAs are already in the SPI flow cache, and the parameters are fetched from there. Even if there is hundreds of tousands of SAs, the rate of new IPsec SAs created per second is very low. I.e. if IPsec SAs has lifetime of 1 hour, that means that every second we create on average of ~30 new IPsec SA flows to keep up 100 000 IPsec SA flows running. Thus the actual heuristics processing only requires to process around that amount of flows. Of course during the monday morning problem the rate will be higher, but even so the heuristics is cheaper than the Diffie-Hellman required to actually create those IPsec SAs, so even low powered CPU should be able to easily to run heuristics on thousands or tens of thousands packets per second. After the heuristics is run then the processing is moved to the actual fast path which only inspects the IPsec SPI flow cache and the src/dst addresses and SPI number found from the packet. > 5) On these High-end appliances, there is a definite need for > load-balancing between flows. That means the amount of the required > memory space will be at least 2x or 3x more, and also there is need for > additional CPU and I/O overhead to maintain two or more loanbalancers in > sync. Heuristics can be run separetely on each devices without any problems, but the
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich wrote: Hi Tero I reviewed your heuristics draft and I believe it is interesting and doable, however: 1) I believe the actual implementation would require more code than current front-end hardware allows. The hardware we work with have a limited space for that much heuristics code. Our preference is to find a quick direct match (in a few instructions max). We would have to respin hardware to allow your heuristics implementation. This might not be implementable today, as hardware respins are costly and take relatively long. 2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's and even tomorrow's implementations will have stateful DPI implemented; these devices have low target COGS and usually do not have simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS. It is unlikely that this would be the potential implementation target for heuristics, as the cost/price would go up. 3) High-end products, e.g. Data Center front-ends, would allow a heuristics implementation; it may have a stateful firewall and/or IDS/IPS and other DPI capabilities, however this class of devices is migrating towards virtualized platforms (major vendors are moving in that direction), and they would be terminating tens or even hundreds of thousands of SAs. 4) Even if these high-end devices have implementations running on multicores, everyone is struggling to provide low latency and high throughput, squeezing the last possible bit through of the pipe. Keeping state until one finds that there is a match or not may introduce unwanted latency and create large memory consumption (multiply everything by e.g. 100K Sas) which we may not be able to afford. 5) On these High-end appliances, there is a definite need for load-balancing between flows. That means the amount of the required memory space will be at least 2x or 3x more, and also there is need for additional CPU and I/O overhead to maintain two or more loanbalancers in sync. 6) Another problem I see is that more traffic today is carried on UDP, and those are inherently difficult to track as "flows". One must keep a significant portion of traffic to determine ESP vs. ESP-NULL. Years ago it was rare and mostly used for implementations such as SNMP, but these days new applications ar ecoming out (e.g. Bittorrent-over-UDP). SIP-over-UDP is another such implementation that may cause problems, if heuristics are implemented in intermediate devices. 7) There will be stateful appliances in the future, but stateless devices will remain in the future; these will not be able to perform heuristics as defined in the heuristics draft. They may have to be redeployed to other places in the network, causing forklift replacements 8) Even by your own conclusion, heuristics are not 100% accurate. There are some "false positives" and some "false negatives" situations. In summary, I find your draft to be interesting, and I am looking forward to seeing it progress on Informational track. I believe also, that a deterministic approach would be quicker and easier. I suggest the "visibility" draft remain on the WG Standards track as it is more implementable. In previous discussions we've reached the conclusion that traffic visibility matters only for a subset of the traffic, where your policy says two things: 1. You intend to do some kind of inspection on the protected payload (could be as shallow as checking ports or as deep as scanning the transported files for malware) 2. You don't allow any ESP that isn't NULL, because then you won't be able to inspect it. ESP non-NULL is dropped. Given that this is the kind of policy we're enforcing, you cannot really escape doing some inspection on the payload - you intend to do this anyway. Even if the packet was "tagged" as the visibility draft suggests, you would still need to verify that the ESP is indeed NULL - you can't rely on a tag. So IMO it doesn't really matter how weak or powerful the edge device is, it has to be powerful enough to inspect all ESP-NULL packets if it is to implement such a policy. If it's not powerful enough, then it can't enforce such a policy, and it doesn't really have to decide whether or not the ESP algorithm is NULL or not. In that case it doesn't have to implement any heuristics. Stateless devices are such a case. They shouldn't care whether or not the traffic is ESP-NULL or not. As for heuristics not being 100% accurate, that is correct, but the chances can be made arbitrarily small, and small enough that we are willing to live with it. Yoav Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Tero I reviewed your heuristics draft and I believe it is interesting and doable, however: 1) I believe the actual implementation would require more code than current front-end hardware allows. The hardware we work with have a limited space for that much heuristics code. Our preference is to find a quick direct match (in a few instructions max). We would have to respin hardware to allow your heuristics implementation. This might not be implementable today, as hardware respins are costly and take relatively long. 2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's and even tomorrow's implementations will have stateful DPI implemented; these devices have low target COGS and usually do not have simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS. It is unlikely that this would be the potential implementation target for heuristics, as the cost/price would go up. 3) High-end products, e.g. Data Center front-ends, would allow a heuristics implementation; it may have a stateful firewall and/or IDS/IPS and other DPI capabilities, however this class of devices is migrating towards virtualized platforms (major vendors are moving in that direction), and they would be terminating tens or even hundreds of thousands of SAs. 4) Even if these high-end devices have implementations running on multicores, everyone is struggling to provide low latency and high throughput, squeezing the last possible bit through of the pipe. Keeping state until one finds that there is a match or not may introduce unwanted latency and create large memory consumption (multiply everything by e.g. 100K Sas) which we may not be able to afford. 5) On these High-end appliances, there is a definite need for load-balancing between flows. That means the amount of the required memory space will be at least 2x or 3x more, and also there is need for additional CPU and I/O overhead to maintain two or more loanbalancers in sync. 6) Another problem I see is that more traffic today is carried on UDP, and those are inherently difficult to track as "flows". One must keep a significant portion of traffic to determine ESP vs. ESP-NULL. Years ago it was rare and mostly used for implementations such as SNMP, but these days new applications ar ecoming out (e.g. Bittorrent-over-UDP). SIP-over-UDP is another such implementation that may cause problems, if heuristics are implemented in intermediate devices. 7) There will be stateful appliances in the future, but stateless devices will remain in the future; these will not be able to perform heuristics as defined in the heuristics draft. They may have to be redeployed to other places in the network, causing forklift replacements 8) Even by your own conclusion, heuristics are not 100% accurate. There are some "false positives" and some "false negatives" situations. In summary, I find your draft to be interesting, and I am looking forward to seeing it progress on Informational track. I believe also, that a deterministic approach would be quicker and easier. I suggest the "visibility" draft remain on the WG Standards track as it is more implementable. _ Dragan Grebovich, CISSP Nortel Networks Enterprise Communication Solutions Product Development Data Systems Strategy and Architecture - Security (978) 288-8069 Billerica, MA 01821 U.S.A ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
