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

[Michael Richardson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>        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[
] [e-mail] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 










-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSvGXlICLcPvd0N1lAQIQ+Af/ViKcqG7Ed9CLVzXbiZOUGUArYJizkO5t
teH+U6DuvPmfX2yLr4cZhEcH5CmhfF6xh2Y2Lg3yc5+IGjk2pqzwn6eRONfP1bwO
8LcFZQ+a215sVCHoFDNFhMzyyMi6i2F/wiyNnSpfEG3HX3gvjonkZJcWKxm6lbyr
uNNPs2BrC11OQcqGsyVXqH1C2T5c42cdauh/Z3U7hxflyf/WNFU3iux3I8SgmgWx
QkZBwp8U60ugbuN/LuA3O72+XXChfQPQppR50aX1RLS86D5UmJoyJvsuA0XOfLSg
qS9H+RWMRk4RgLiO4DrlwhYVoKznhwf48XTaCTa8nPT+rT2ffLzepA==
=H/OJ
-----END PGP SIGNATURE-----