ipsec October 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heu

Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01

From: Tero Kivinen <kivinen_at_nospam>
Date: Wed Oct 14 2009 - 11:36:20 GMT
To: Nicolas Williams <Nicolas.Williams@sun.com>


Nicolas Williams writes:
> - Section 7, 1st paragraph: MOBIKE is mentioned without a reference.
> - Section 7, 2nd paragraph: s/avare/aware/
> - Section 8.1, next to last sentence: this sentence is grammatically
> incorrect, I think. How about:
> If the protocol (also known as the, "next header") of thepacket is
> one that is not supported by the heuristics, then detecting the IV
> length is impossible, thus the heuristics cannot finish.
> - Section 8.2, 2nd paragraph: s/shorted/shortest/
> - Section 8.2, 2nd paragraph, 2nd sentence:
> s/implementation/the implementation/
> - Section 8.2, 2nd paragraph, 2nd sentence:
> s/valid looking/valid-looking/
> - Section 8.2, bottom of page 15: s/insure/ensure/ (yes, nowadays your
> use if 'insure' in this way is quite common)

All fixed.

> - Section 8.2, next to last paragraph, next to last sentence: I'm not
> sure what is meant. Can you try to re-write this sentence? How
> about:
>
> By counting how many "unsure" returns obtained via heuristics, and
> after the receipt of a consistent, but unknown, next-header number
> in same location (i.e., likely with the same ICV length), the node
> can conclude that that flow has a high probability of being
> ESP-NULL (since it's unlikely that so many packets would pass the
> integrity check at the destination unless they were legitimate).
>
> (The key change is the addition of a comma and moving a clause into a
> parenthetical.)

Changed to:

    <t>An intermediate node's policy, however, can aid in detecting an     ESP-NULL flow even when the protocol is not a common-case one. By     counting how many "unsure" returns obtained via heuristics, and     after the receipt of a consistent, but unknown, next-header number     in same location (i.e. likely with the same ICV length), the node     can conclude that the flow has high probability of being ESP-NULL     (since it is unlikely that so many packets would pass the     integrity check at the destination unless they are legitimate).     The flow can be classified as ESP-NULL with a known ICV length,     but an unknown IV length.</t>

> - Section 8.3, 1st paragraph, 2nd sentence: this sentence is
> grammatically incorrect, and I'm unsure as to what is meant.

This was commented already by others and was changed to:

    For example, when many TCP / UDP flows are established over     one SA, a rekey produces a new SA which needs heuristics and will     benefit from the existing flows.

> I think what is meant is that if an intermediate node has seen a
> stateful ULP flow over an ESP-NULL flow, and later the SA is changed
> and the new flow looks like ESP-NULL and appears to contain a next
> protocol header that matches that previously-seentateful ULP flow,
> then chances are very good that the old ESP-NULL flow is abandoned
> and replaced by the new one. In such situations the intermediate
> node can simply change the old ESP-NULL state's lookup key.

Yes. That was what I tried to say. Do you think my already changed sentence is ok, or do we need to explain it more.

> - Section 8.3.1, 1st paragraph, 1st sentence: s/feed/fed/

Fixed.

> - Section 8.3.1, third paragraph: are you suggesting that intermediate
> nodes drop TCP-looking packets to elicit retransmission?

It says that "if a packets is dropped", i.e. it does not say whether the intermediate node does or does not do it, as that depends on the policy. If the intermediate node's policy is that no packets go through before they can be inspected meaning ESP-NULL detection needs to finish first before they can be inspected, that will cause all packets to be dropped while heuristics is in progress. This will cause next packets to be retransmissions.

If the policy is so that packets are passed, even when we cannot yet inspect them, then the next packet still might be to the same flow.

> - Section 9, 1st paragraph, 1st sentence, I think you may want to make
> this change:
> s/unless that is not/unless that is/

Yes. Fixed that.

> - Section 9, 1st paragraph, 1st sentence: this is an odd sentence
> construction. How about:
> Attackers can always bypass ESP-NULL deep packet inspection by
> using encrypted ESP (or some other encryption or tunneling method)
> instead, unless the intermediate node's policy requires dropping
> of packets that it cannot inspect.
> - Section 9, 1st paragraph, 2nd sentence, rewrite:
> Ultimately the responsibility for performing deep inspection, or
> allowing intermediate nodes to perform deep inspection, must rest
> on the end nodes.
> - Section 9, 1st paragraph, last sentence: s/but in that/in which/

Ok, took all of those in, here is the current version of section 9:

    <t>Attackers can always bypass ESP-NULL deep packet inspection by     using encrypted ESP (or some other encryption or tunneling method)     instead, unless the intermediate node's policy requires dropping     of packets that it cannot inspect. Ultimately the responsibility     for performing deep inspection, or allowing intermediate nodes to     perform deep inspection, must rest on the end nodes. I.e. if a     server allows encrypted connections also, then attacker who wants     to attack the server and wants to bypass deep inspection device in     the middle, will use encrypted traffic. This means that the     protection of the whole network is only as good as the policy     enforcement and protection of the end node. One way to enforce     deep inspection for all traffic, is to forbid encrypted ESP     completely, in which case ESP-NULL detection is easier, as all     packets must be ESP-NULL based on the policy, and further     restriction can eliminate ambiguities in ICV and IV sizes.</t>

> - Section 10.2, an informative reference to MOBIKE is needed. What
> about multicast IPsec?

Added reference to MOBIKE.

I do not think multicast IPsec requires any special handling as the level what we need for them is already in the RFC4301/RFC4303. We do not really care about the keying protocols, we only care about the ESP packets and we use source address, destination address and SPI to indicate IPsec flow as specified in the RFC4301 and RFC4303. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec