On 11/8/12 3:26 AM, "Johannes Merkle" <johannes.mer...@secunet.com> wrote:
>Hi Tero, > >> Every single option adds complexity, so I do not think we should add >> more optional things. > >Point compression is not the focus of our draft. Given the opposition it >is facing here, I suggest to wait for further >replies and if point compression turns out to be objected by the majority >on this list, I will not insist on this feature. >BTW: In an earlier thread Dan Haskins has already indicated his >preference to leave point compression out. > >> >> Not sending the CERT, but replacing it with hash and url offers much >> bigger savings, and people are not even doing that. >You can not be sure that this option isn't used is some constrained >environments. > >Just a note: the relative saving of point compression is larger when >sending hash + URL instead of the CERT. What's the scenario here? If hash + URL is sent, the certificate still has to be retrieved. It might not be part of the IKE exchange, but moving it to HTTP doesn't mean that it doesn't contribute to bytes on the wire (or over the air, in the case of wireless). David > >> >> Note, that negotiating the use of point compression without retry or >> not would waste more bytes then the point compression saves... The KE >> payload is in the first packet, which means that to be able to >> negotiate it beforehand would require one extra roundtrip. The IKEv2 >> headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes >> which is already quite big EC key Y part... > >What I had in mind are constraint environments where using bandwidth >saving techniques like point compression can be >assumed to be the default. > > >> If I remember right the reason IKEv2 does not use point compression >> for the current groups was that there was some IPR. Is that issue >> already been cleared? > >The the patent expires in 2014. >http://cr.yp.to/patents/us/6141420.html > >-- >Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
