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: Nicolas Williams <Nicolas.Williams_at_nospam>
Date: Tue Oct 13 2009 - 18:34:25 GMT
To: Yaron Sheffer <yaronf@checkpoint.com>

  • 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 -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec