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

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]