pasi.ero...@nokia.com writes:
> 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.
Ups. And it seems to affect the calculations, so need to recalculate
them too...
> > > - 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).
Ok, I removed that part of pseudocode.
>
> <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.
Ok, removed the ", meaning it might have more bugs than ESP
implementations" part. Would this text be ok:
AH has also quite complex processing rules compared to ESP when
calculating the ICV, including things like zeroing out mutable
fields, also as AH is not as widely used than ESP, the AH support
is not as well tested in the interoperability events.
or do you think we should leave only the complexcity issue:
AH has also quite complex processing rules compared to ESP when
calculating the ICV, including things like zeroing out mutable
fields.
> 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.
Hmm... true... Ok. I removed the IPv6 vs NAT text so the pragraph
looks like this:
All of the aforementioned drafts require modification to ESP,
which requires that all end nodes need to be modified before
intermediate devices can assume that this new ESP format is in
use. Updating end nodes will require lots of time. An example of
slow end-node deployment is IKEv2. Considering an implementation
that requires both IKEv2 and a new ESP format, it would take
several years, possibly as long as a decade, before widespread
deployment.
I will submit new draft tomorrow (before I leave for one week long
vacation).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
