Subject: [IPsec] comments on esp-null-heuristics-01

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2009 10:02:46 -0500

>        As end nodes might be able to
>   bypass those checks by using encrypted ESP instead of ESP-NULL, these
>   kinds of scenarios also require very specific policies to forbid such
>   circumvention.

The question is, are these end-nodes malicious, or are they just
ignorant?

>   Because the traffic inspected is usually host to host traffic inside
>   one organization, that usually means transport mode IPsec is used.

It is?  I'll bet 95% of actual transport mode IPsec has an L2TP layer inside.

===

I agree with the analysis of section 3, in particular the explanation of
how hardware can be programmed to statefully match the ESP-NULL flows.
It might be worth noting that NAT-T ESP-NULL flows *ALREADY* have a
5-tuple (likely unique) marker, and that if the inspector is also a NA(P)T,
that it already is keeping the right state.

section 4.

It might be worth having a reference for "flow cache". I think that
there is a document on Cisco Netflow, and I also think that FORCES has
something that relates to the Linux "flow" things.  I think it might
also be worth staying that this is really a "microflow" cache.

Include a forward reference to section 7, so the reader knows UDP will
be dealt with.  In particular, in the text relating to NAT-T
encapsulated IKE packets.   If they are not allowed through (queue until
sure, or drop option), then the SA might not get setup ever..

section 8.2

I'd rather see the math/calculations in a display... that would
eliminate the difficulty in reading when things are wrapped.

page 16:

   those cases the packet must be marked "unsure".

s/must/MUST/ ???

I have read the appendix code, and I do not see anything glaringly out
at me,  but I'd have to sit down and actually implement to know if all
the situations are taken care of.

It seems like good guidance, and the statements in the Appendix were
familiar from reading the text.

In conclusion: while I think the whole inspection notion is ridiculous,
               and likely is going to get in the way of deployment of
               new protocols, and may well help the "throttlers"
               (cf. Mark Handley's Net Neutrality presentation at
               IETF75), I find that if the inspection people follow the
               very sage advice of Kivinen and McDonald, that the least
               amount of harm possible will be done.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Nov 2009 15:53:34 +0200 (EET)

> The question is, are these end-nodes malicious, or are they just

Good question, and I do not have good answer to that, as I do not
think we have clear threat model for WESP / heuristics. 

> It is?  I'll bet 95% of actual transport mode IPsec has an L2TP layer inside.

Inside one enterprise? I do not think so. I guess most of the IPsec
traffic is VPN style tunnel mode, but as that is going over untrusted
networks (there is word private there :) they are encrypted, thus
outside the scope of this draft.

Same goes with the L2TP transport mode cases.

I added a note there saying:

  Note, that most of the current uses of the IPsec are not host to
  host traffic inside one organization, but for the intended use cases
  for the heuristics this will most likely be the case. Also tunnel
  mode case is much easier to solve than transport mode as it is much
  easier to detect the IP header inside the ESP-NULL packet.

> that it already is keeping the right state.

Do you have any exact wordings where to add what. 

> also be worth staying that this is really a "microflow" cache.

I added new terms to terminology section saying:

   Flow

      TCP/UDP or IPsec flow is a stream of packets part of the same TCP/
      UDP or IPsec stream, i.e.  TCP flow is a stream of packets having
      same 5 tuple (source and destination ip and port, and TCP
      protocol).

   Flow Cache

      Deep inspection engines and similar use cache of flows going
      through the device, and that cache keeps state of all flows going
      through the device.

   IPsec Flow

      IPsec flow stream of packets having same source IP, destination
      IP, protocol (ESP/AH) and SPI.  Strictly speaking source IP does
      not need to be as part of the flow identification, but as it can
      be there depending on the receiving implementation it is safer to
      assume it is always part of the flow identification.

> sure, or drop option), then the SA might not get setup ever..

Hmm... I think it should be enough to cover UDP encapsulation in the
section 7, do you really think we need forward reference from here? If
so, can you give me some exact text?

> eliminate the difficulty in reading when things are wrapped.

Done. 

>    those cases the packet must be marked "unsure".

I do not use RFC2119 words in the document as this is not really
protocol description. Changed the text to: In those cases the packets
are marked as "unsure".

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Nov 2009 16:32:11 +0200 (EET)

Michael Richardson writes:
>     Tero> Inside one enterprise? I do not think so. I guess most of the
>     Tero> IPsec traffic is VPN style tunnel mode, but as that is going
>     Tero> over untrusted networks (there is word private there :) they
>     Tero> are encrypted, thus outside the scope of this draft.
> 
>   I see the "inside one organization" part now.
>   I was thinking that much of the transport-mode traffic crossing an
> enterprises' border is likely on-site consultants, who are doing remote
> access back to their HQ.

Yes, but those consultants do use encryption when connecting to the
enterprise network.

Most likely their encrypted traffic is terminated on the security
gateway on the enterprise network border, and then it might go forward
without encryption (it might have end to end ESP-NULL inside the
encrypted tunnel mode ESP when it arrives to the sgw, and sgw might
strip encrypted tunnel mode ESP out and leave transport mode ESP-NULL
inside).

>     Tero> I added a note there saying:
> 
>     Tero>   Note, that most of the current uses of the IPsec are not
>     Tero> host to host traffic inside one organization, but for the
>     Tero> intended use cases for the heuristics this will most likely be
>     Tero> the case. Also tunnel mode case is much easier to solve than
>     Tero> transport mode as it is much easier to detect the IP header
>     Tero> inside the ESP-NULL packet.
> 
>   I think that's 5%, with 95% being above, but maybe I don't know why
> this stateful inspection device is "inside"

It is "inside" as I do not belive anybody belives they could leave
encryption off for traffic that goes outside of the enterprise...

Remember that all of this is always talking about ESP-NULL traffic
only.

> 
>     >> I agree with the analysis of section 3, in particular the
>     >> explanation of how hardware can be programmed to statefully match
>     >> the ESP-NULL flows.  It might be worth noting that NAT-T ESP-NULL
>     >> flows *ALREADY* have a 5-tuple (likely unique) marker, and that
>     >> if the inspector is also a NA(P)T, that it already is keeping the
>     >> right state.
> 
>     Tero> Do you have any exact wordings where to add what.
> 
>   I think that there is later on text about this, and maybe just a
> forward reference is enough. 
>         "As described in section 7, UDP encapsulated ESP traffic
>         may also have have NAPT applied to it, and so there is already
>         a 5-tuple state in the stateful inspection gateway

Ok, added that to the end of section 3. "

>     Tero>    Flow
>     Tero>       TCP/UDP or IPsec flow is a stream of packets part of the
>     Tero> same TCP/ UDP or IPsec stream, i.e.  TCP flow is a stream of
>     Tero> packets having same 5 tuple (source and destination ip and
>     Tero> port, and TCP protocol).
> 
>   okay, I would run this by the transport and Internet area folks,
> because I think this disagrees with their definition of flow.

How does that disagree in their definition of flow?

On the other hand it really does not matter whether it disagrees or
not, this is what we mean by flow in this document, so as we define it
there, it should be clear for people what we mean by flow.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 16:00:30 +0200 (EET)

Michael Richardson writes:
>     Tero> How does that disagree in their definition of flow?
> 
> A flow in the routing and ASIC space is an origin/destination IP address
> pair only.  A microflow is the 5-tuple.

Never heard about microflow before.

Wikipedia says:

    Applied to Internet routers, a flow may be a host-to-host
    communication path, or a socket-to-socket communication identified
    by a unique combination of source and destination addresses and
    port numbers, together with transport protocol (for example, UDP
    or TCP). In the TCP case, a flow may be a virtual circuit, also
    known as a virtual connection or a byte stream.

It also says it could be "a sequence of packets from a source computer
to a destination", which would match other flow definition, so I guess
there is no one standardized definition...

Wikipedia does not know anything about microflows...

RFC2474 seems to be the one which defines microflow, and RFC2991
defines flow to be "represent the granularity at which the router
keeps state", which might be just source and destination addresses, or
it might contain protocol id, and RFC2991 also says that "flow" is not
necessarily synonymous with the term "microflow", but does not also
say it cannot be.

Deep inspection engines usually keep state on granularity of port
numbers, so I do not think the flow definition we use here is
inheritly different from RFC 2991.

Then for example rfc4821 (Packetization Layer Path MTU Discovery)
defines flow to be:

Flow:  A context in which MTU Discovery algorithms can be invoked.
      This is naturally an instance of a Packetization Protocol, for
      example, one side of a TCP connection.

and RFC5626 (Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)) says:

   Flow:  A Flow is a transport-layer association between two hosts that
      is represented by the network address and port number of both ends
      and by the transport protocol.  For TCP, a flow is equivalent to a
      TCP connection.  For UDP a flow is a bidirectional stream of
      datagrams between a single pair of IP addresses and ports of both
      peers.  With TCP, a flow often has a one-to-one correspondence
      with a single file descriptor in the operating system.

so I do not think there is one agreed on definition of flow.

>     Tero> On the other hand it really does not matter whether it
>     Tero> disagrees or not, this is what we mean by flow in this
>     Tero> document, so as we define it there, it should be clear for
>     Tero> people what we mean by flow. 
> 
> Well, your document will be read by ASIC designers and they already have
> a definition of flow and microflow, and if you want to confuse them,
> then that's fine.

I do not want to use definition that would confuse all others either.
It is bad if one group of people is confused, but don't really want to
confuse other people by using term they do not know (including me).

Perhaps the best way is to say in the terminology definition of flow
that in some context (diffserv and bhp) this is called microflow.
-- 
[email-masked]