Re: [IPsec] Motivation for ESP-null marking

[Tero Kivinen <kivinen at iki.fi>]

Grewal, Ken writes:
> >I think there is no point of doing this on the protocol level as to
> >deploy it requires changes to ALL IPsec endpoints.
> 
> [Ken] It will only require changes to nodes that choose to utilize
> this functionality, which is probably the same statement for any
> other work item in IETF today. If it is not needed (e.g. remote
> access / VPN), then those nodes can operate as they do today. 

If we are talking about the enterprice checking traffic in their
internal network, that most likely means that everything using ipsec
will needs to be updated, i.e. both ends of the IPsec connections.
Heuristics only require updating the middleboxes. This is bit similar
than IPv6 vs NAT. IPv6 require updating of all end nodes (and
infrastructure), as NAT only required middle boxes to be added, and no
changes at all to the end nodes. As you can see in the deployment
timeline of IPv6 vs NAT, you can see how much faster we can update
middle boxes... 

> [Ken] This argument is applicable to any charted work item and the
> deployment timelines will be dependent on many factors, including
> the perceived usefulness of the feature, as well as alternatives
> available. A heuristics based solution may be less desirable, as
> anytime a new protocol/extension is encapsulated in IPsec, the
> heuristics need to be updated to comprehend it.

Anytime a new protocol goes through any box doing deep inspection, the
box needs to be updated anyways, as otherwise the new protocol will
not get passed through that box (deep inspection boxes quite commonly
drop everything they will not understand). On the other hand
heuristics only needs to be updated if no known protocols will go
through the deep inspection box at all. I.e. if there is NO TCP or UDP
traffic going inside the ESP-NULL flow at all, then the deep
inspection box needs to understand the new protocol, so it can run
heuristics on that too.

In normal case there is still TCP and UDP traffic going, so it can
simply run the heuristics on those packets and find out the parameters
of the ESP-NULL flow from there. After that they are cached to the
box, and no heuristics is needed until the SA is rekeyed. 

> Having said that, perhaps it is possible to devise a solution that
> will work for all protocols/payloads of today and tomorrow?  If so,
> we'd very much like to see it fully specified in a draft submission.
> That will make it much easier to evaluate the relative feasibility
> and practicality of the heuristic approach, compared to our
> proposal.

Even when you are only checking the ESP padding, that already gives
you quite good probability for running the heuristics with even a
single packet with completely unknown protocol inside the ESP-NULL
packet. The worst case is when there is no padding, thus there is only
Pad-length field having value of 0, so every 1/256 packets goes
through this check. If there is for example 2 bytes of padding (it
needs to be padded to 4-byte boundary), then there is 2 bytes of
padding and 1 padding length byte, which all needs to have specific
values (i.e. 01 02 02). That makes it so that 1 packet out of 16777216
will pass that first check.

I am writing the pseudocode for the heuristics, but it might take
some more time before I get that one ready. 

> >I do not see any reason why both ESP-NULL and encrypted ESP shuld be
> >allowed between 2 end nodes, i.e. I see only reason where there is
> >either only ESP-NULL allowed or only any type of ESP allowed (i.e.
> >encrypted or not, but not inspected at all).
> 
> [Ken] This is a matter of policy and we should not offer a pure
> black-or-white choice. Why don't we just remove NAT and use AH in
> these environments? Why did we propose a NAT-T solution at all? We
> cannot mandate how an organization will structure the network (hence
> the NAT-T solution) and similarly we cannot predict or dictate what
> protocols/encapsulations/algorithms it should run over that network.

But if the idea is that the deep inspection boxes check the packets
going through them, then they cannot inspect those packets which are
encrypted, and if specific end node pairs are allowed to have both
encrypted and un-encrypted packets, why would the "attacker" use the
un-encrypted packets that will be inspected. He would of course use
the encrypted packets so they will bypass the inspection if he is
trying to do something that is not allowed.

> >If both ESP-NULL and encrypted ESP is allowed between pair of end
> >nodes, then anybody who wants to bybass middlebox checks will simply
> >use encrypted ESP. If someone disagrees with this, I would like him to
> >explain me why this is needed, and what kind of policy is used for
> >that.
> 
> [Ken] This is negotiated via policy, which is under the admin's
> control. E.g. If the policy states that my company CEO (based on his
> credentials used during IKE) is able to connect to a particular
> server using encrypted ESP, whereas Joe Bloggs must use ESP-NULL to
> allow traffic scanning, why could this not be allowed?

So in this setup you are not doing security checking anymore in the
middlebox, but you are trusting your end SGW to enforce security
policy. If you are doing that, you might as well trust for the end SGW
to do full security policy checking.

Heuristics would work in that kind of situations too, but then the
default what happens when the heuristics fail to check that packet is
ESP-NULL is different (i.e. pass, instead of drop). Of course there is
no way to check that the Joe Bloggs is not using ESP encrypted traffic
in this setup, as you allow encrypteed ESP to go through. The SGW on
the other end might have policy which only allows ESP null for Joe
Bloggs, but if it is misconfigured for some reason, then Joe might be
able to bypass security checks. If the middlebox was put there to
enforce the security checks, then it cannot do that anymore.

> >Also if IT department has full control of the end node
> >configurations (which they must have if they assume they can update
> >all end node implementations at will) they can simply mandate them to
> >use one specific ESP-NULL algorithim, i.e. simply say that no other
> >ESP-NULL algoritm is allowed except AUTH_HMAC_SHA1_96, and that will
> >remove all heuristic checks needed. This kind of solution is
> >implementatable in extremely fast timeframe.
> 
> [Ken] This may be viable in small organizations, but is not
> practical in a large organization, unless a 'forklift upgrade' is
> used. Also, we need to consider legacy devices (e.g. secure printing
> using an older algorithm - Do I really want to upgrade all my
> printers because I choose to use GMAC for other secure comms and my
> printer is using HMAC-SHA-1-96?). This is just a simple example for
> illustration purposes. 

If you decide that GMAC is the only one offering enough security for
you, then you do want to upgrade your printers too. If you consider
HMAC-SHA-1-96 to be enough then you can use that for all of your
traffic. If you want to allow your printers to use the new ESP-NULL
protocol then you need to upgrade them anyways. 

> [Ken] The remainder of your comments above relate to Heuristics and
> where these are implemented. This could be in HW or firmware or SW
> and not all implementations are equally amenable to upgrade options
> or tolerant of performance requirements. Also, the practically of
> heuristics based approaches at high speed line rates (10Gbps today,
> 40/100Gbps tomorrow) can be costly and dependent on the hardware
> architecture, whereas a new ESP encapsulation would work fine
> regardless.

I do not really see any real performance differences between the new
ESP encapsulation vs heuristics in the hardware, especially anything
that does any kind of deep inspection. For boxes that do deep
inspection there is already flow tables for TCP flows and such, so
adding SPI flows for mappng SPI numbers to parameters is quite fast
thing to do. All of the complicated heuristics are usually run on the
slowpath anyways.

> Furthermore, any changes to any ESP encapsulated
> protocols will require changes / additions to the heuristics
> approach, making this approach a continuous, moving target. 

We can very easily make the heuristics extremely effective and fast by
saying that IPsec implementations should but extra 4 bytes of padding
to each ESP-NULL packet. This offers very fast and very easy way to
check whether packet is ESP-NULL or ESP encrypted packet without doing
actual protocol change. But deep inspection is always moving target
regardless what we dowith the ESP, thus the middle boxes needs to be
updated every time any protocols or additions are going to be made.
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec