Subject: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01

From: Tero Mononen <[email-masked]>
Date: Thu, 19 Nov 2009 10:43:31 +0200

Tero, Dan and others,

I've read your informational draft.

Overall comments:

  The draft contains quite a lot of background information (what you are
  trying to achieve on technical point of view, what were the
  alternative solutions considered). Part of this background is also
  available on WESP draft.

  Making this draft an information disclosure on "algorithm to
  determine if IPsec ESP packet stream has been encrypted or not",
  without too much explanation or hand waving would increase its
  usability. The background could be find by-reference on the WESP
  RFC.

  Please consider adding definitions/glossary entries for the
  following concepts: flow, flow-cache. I know they are relevant on
  certain implementations, but not necessarily well defined on that
  sense, or at least introducing these terms properly before using
  them.

About the abstract:

  Consider changing abstract in a way that really points out the
  good on this approach. Something like:

-8<---

  This document describes an algorithm for distinguishing IPSEC
  ESP- NULL packets from encrypted ESP packets.  The algorithm can
  be used on intermediate devices, like traffic analyzers, and deep
  inspection engines, to quickly decide whether given packet flow is
  interesting or not. Use of this algorithm does not require any
  changes made on existing RFC4303 compliant IPSEC hosts.

-8<---

About the algorithm:

  Pseudo-code seems sane, and was understandable after reading the
  specification part. However I did not try to implement it, nor
  really proof its correctness.

P.S. Please ignore the following meaningless whining:

About Security Considerations:

  Raises a question, why is this all needed? What is the use case?
  Neither this, nor WESP draft can give a simple answer for the
  question. If encrypted traffic is allowed to pass traffic
  analyzer/intrusion detector/intrusion prevention/firewall/whatever,
  the malicious end nodes will use encryption. If encrypted traffic
  is dropped by intermediate, then there is an end node policy
  issue.  Detection whether an ESP packet payload is encrypted or
  not should already be fast on deep inspection packet matching
  hardware.

--
Tero Mononen <[email-masked]>

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 19 Nov 2009 10:42:27 -0800

Hi Tero,

Let me answer the very relevant question you have raised and got no
reply for yet. Let me first give you a short background.

We had a similar discussion on ESP-NULL versus AH and merits of a
heuristics  approach in 2007 on the SAAG list. You can have a look at
the discussion
http://www.ietf.org/mail-archive/web/saag/current/msg01933.html and
the related mails.

Tero Kivinen's point at that time too was that we can do heuristics
based approach. Also look at the archive
http://www.ietf.org/mail-archive/web/ipsec/current/msg01902.html of
the question I had raised.

>  not should already be fast on deep inspection packet matching

Like mentioned in the mail assume an application that runs within an
enterprise and uses ESP-NULL only service. We could filter out all
packets for that application port at the firewall itself as we can
look deeper into the packet if we had a mechanism to know if the
packet is encrypted or not.

So if an encrypted packet came for an SA which used ESP-NULL, it would
not be processed properly and dropped like you mentioned by the
application anyway. However by knowing ESP-NULL at the edge we could
drop packets for applications from domains disallowed to send packet
in (even though the packets are replayed packets and so will actually
be treated as correct packets by the application).

This is also one reason an application may use ESP-NULL, that way
firewalls can do their work and the application is safe from being
bombarded by packets from outside the domain. The use cases of doing
the detection of ESP-NULL versus encrypted packets however are
limited.

Thanks,
Vishwas

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Nov 2009 15:43:38 +0200

>   usability. The background could be find by-reference on the WESP

I think having background information in this document also makes this
document easier to understand. WESP document actually has quite a
little of the background information.

>   sense, or at least introducing these terms properly before using

I added terminology section and added those terms there.

>   changes made on existing RFC4303 compliant IPSEC hosts.

Changed.
-- 
[email-masked]