Tero Kivinen wrote: > > - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not > > defined for IPsec ESP; these algorithms apply only to the > > FiberChannel security protocols. So they should be removed from > > this list (and since this was the only algorithm with 160-bit ICV, > > handling that case can be removed). > > Removed.
Section 8.2 still has some old text that assumes five (instead of four) different ICV lengths. <snip> > > - Appendix A.2, "Verify TCP": the bits that are currently reserved > > might get allocated in the future (and half of the bits that were > > reserved in RFC 793 have been since allocated -- so it's not very > > clear exactly what "TCP.reserved_bits" means). > > All of those tests are something that depends on other standards, i.e. > TCP. Normally deep inspection engines etc will check all kind of TCP > fields, and depending on the them does something (drop, pass, clear, > set, modify etc), and usually those people writing the deep inspection > engines etc have quite good idea which bits they can check and which > not. > > The reason we do not explictly mention what reserved_bits is just > because it can change in future. The reserved bits MUST be ignored if you don't understand them, so testing whether they're zero (and returning failure if they're not) is not correct behavior here (and would unnecessarily complicate deployment of new TCP features in the future). <snip> > > - Section 2.1, suggesting that AH might have more bugs doesn't sound > > like an argument that belongs in this document. > > It was one of the arguments which was given when people said why they > do not want to use AH. Nevertheless, as it's currently written, it sounds more like FUD than a reasonable argument. Let's just delete it. > > - Section 2.3: the discussion about IPv6 and NATs does not belong in > > this document. > > I am trying explain there why I do not belive that modifying all end > peer is that easy thing to do, and modifying the intermediate devices > instead is much faster to deploy. > > I think it provides reasons why people might want to implement this > even when WESP is the other alternative. I understand the argument you're making, and I think for ESP-NULL heuristics, it's a reasonable argument. But the comparison to IPv6 is very misleading here -- I think many folks would argue that for IPv6 it's been easier to update the end nodes (many of which do support IPv6 today) than the intermediate nodes (when e.g. travelling, how often do you find that the routers/whatever in the access network actually provide v6?). And probably some folks would say this argument is too simplistic and wrong, too -- either way, it's not a discussion for this document. Best regards, Pasi _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
