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

From: Yaron Sheffer <[email-masked]>
Date: Tue, 13 Oct 2009 19:29:43 +0200

Hi everyone,

To date we've had only two last call reviews of this document. Please consider this a personal invitation to be the lucky third. We simply cannot advance the document unless we're convinced it's had adequate review.

We are hereby extending the WGLC by another 2 weeks, until Oct. 27.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yaron Sheffer
> Sent: Thursday, September 17, 2009 23:28
> To: [email-masked]
> Subject: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
> 
> This is to begin a 2 week working group last call for draft-ietf-ipsecme-
> esp-null-heuristics-01. The target status for this document is
> Informational.
> 
> Please send your comments to the ipsec list by Oct. 1, 2009, as follow-ups
> to this message.
> 
> Note that this document has had very little review until now. We will only
> progress it as a WG document if we have at least 3 non-editor, non-WG
> chair reviewers who have read it and approve of it. And yes, this means
> the pseudocode, too. There has been strong support of ESP-null detection,
> so this document is likely to be widely implemented. Your review will mean
> a lot to the technical quality of this document.
> 
> Please clearly indicate the position of any issue in the Internet Draft,
> and if possible provide alternative text. Please also indicate the nature
> or severity of the error or correction, e.g. major technical, minor
> technical, nit, so that we can quickly judge the extent of problems with
> the document.
> 
> The document can be accessed here:
> http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01
> 
> Thanks,
>             Yaron
> 
> 
> Email secured by Check Point
> 
> Email secured by Check Point
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Oct 2009 13:34:25 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Oct 2009 13:35:23 -0500

Note: I did not review the appendix nor its sub-sections.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Oct 2009 13:54:58 -0500

> Done.

One more comment:

 - State keeping by intermediate nodes is described as an optimization,
   however: a) I'm not sure that that necessarily follows, since state
   keeping and cache index lookups are not free, and anyways, b) in some
   cases, particularly where the next header is TCP or UDP, state
   keeping appears to be a requirement for establishing confidence in
   heuristics results.

   (b) is the key issue.  Some advice on state cache sizing may be
   useful.  E.g., if an entry is dropped out of the cache due to cache
   pressure, how costly will that be in terms of additional inspection
   effort for future packets for that flow, and in terms of resulting
   future cache pressure?

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Oct 2009 13:06:45 -0700

Thanks, Nico! However...

>Note: I did not review the appendix nor its sub-sections.

Please do. :-)

Seriously, folks, the appendix is pretty important, inasmuch as some developers will pay more attention to it than they do the main body. It would be really good to have some folks review it to make sure that they proposed checks and actions match those of the main body, and that they seem sane.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Oct 2009 14:36:20 +0300

>    use if 'insure' in this way is quite common)

All fixed.

>    (The key change is the addition of a comma and moving a clause into a

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>

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

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

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

>    s/unless that is not/unless that is/

Yes. Fixed that.

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

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.
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Oct 2009 12:38:52 -0500

> sentence is ok, or do we need to explain it more.

Well, the heuristics will benefit from the information cached for the
TCP/UDP flow over the previous SA.  "...benefit from the existing flows"
doesn't quite get that point across (though it's the only realistic
meaning).

> next packets to be retransmissions.

But surely actively trying to elicit retransmissions could be used
as a way to get enough information to classify a flow...  The
retransmissions should have different MACs, thus retransmissions
help resolve ambiguities, even if the policy isn't to drop packets that
cannot be inspected.

> inspect them, then the next packet still might be to the same flow.

I see.  Having a policy that says "drop packets that can't be inspected"
actually helps resolve ambiguities if the end nodes retransmit.

>     restriction can eliminate ambiguities in ICV and IV sizes.</t>
                 ^
		 s

Great!

> indicate IPsec flow as specified in the RFC4301 and RFC4303.

Thanks.

A few more comments:

 - Should there be an explicit threat model in the document?  I think
   the threat model is this:

    - End nodes trying to access inappropriate data, end nodes trying
      sneak confidential data out, but without collusion with other end
      nodes outside the network.

    - Malware (since deep inspection could find malware and terminate
      flows before malware downloads complete).

   The first one shows how simple it is to defeat deep packet
   inspection: just find a peer to collude with.

 - A security considerations note about the security impact of forcing
   the use of ESP-NULL (and/or WESP) would be nice.  Specifically a note
   about the increased risk of sending confidential information where
   eavesdroppers can see it.

I will review the pseudo-code at some point.  I've reviewed the fast
path already, and it seemed OK (and it seemed to underscore the point
that state is actually needed for reasons other than optimization).

The thought occurred that the pseudo-code could be expressed as a BSD
Packet Filter program.  From what I can tell BPF does not have
instructions by which one can implement state caching, but you could
still implement, and _test_, large parts of the code in the appendix as
BPF programs.  I wouldn't demand that -- it's a lot of work for a
feature that we all seem to agree is not exactly hot (and it might mean
doing implementation work for some vendors for free).

Nico
--