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

[Tero Kivinen <[e-mail]>]

Michael Richardson writes:
> >        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?

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

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

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.

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

Do you have any exact wordings where to add what. 

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

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.

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

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?

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

Done. 

> page 16:
> 
>    those cases the packet must be marked "unsure".
> 
> s/must/MUST/ ???

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

> 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.
-- 
[e-mail]