-----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[ ] m...@sandelman.ottawa.on.ca 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----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec