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

[Nicolas Williams <[e-mail]>]

 - 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)

 - 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.)

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

   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.

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

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

 - Section 9, 1st paragraph, 1st sentence, I think you may want to make
   this change:

   s/unless that is not/unless that is/

 - 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/

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

Done.

Nico
--