[anonsec] Fwd: [openikev2-announce] New versions released !!!

Hi Yoav, hi all,

thanks for forwarding this message to the Anonsec/BTNS mailing list ... and you are right; we are currently supporting BTNS as part of our
implementation of the IKEv2 protocol (http://openikev2.sourceforge.net/); it is working well with SAB mode and we are finishing now the coding of the
Channel Binding (CBB) mode.

Thanks, regards, Gregorio

Gregorio Martinez, PhD
University of Murcia (UMU), Spain

Post by Yoav Nir
Hi.
Thought this would be of interest to the list.
Apparently they have BTNS support.

*From: * Alejandro Perez Mendez <alejandro_perez at dif.um.es
<mailto:alejandro_perez at dif.um.es>>
*Date: * July 27, 2007 4:16:36 AM CDT
*To: * OpenIKEv2 announces <openikev2-announce at dif.um.es
<mailto:openikev2-announce at dif.um.es>>
*Subject: * *[openikev2-announce] New versions released !!!*
New versions released !!!
* Intensive use of the RAII programming idiom
(autopointers, autolocks, autovectors...),
avoiding the use of the "delete".
* Use of references when there was no need for
more.
* Name classes changes, to avoid the "_" at most
as possible.
* Code factorization, reusing the code for the
CHILD SA negotiation from the IKE_AUTH and the
CREATE_CHILD_SA exchanges. Also the code for the
IKE_SA negotiation from the IKE_SA_INIT and
CREATE_CHILD_SA exchanges has been factorized.
* BTNS support added (that's is, no authentication at all
at IKEv2 level)
* Lot of bug fixes.
* Intensive use of the RAII programming idiom
(autopointers, autolocks, autovectors...),
avoiding the use of the "delete".
* Use of references when there was no need for
more.
* Name classes changes, to avoid the "_" at most
as possible.
* Disabled PFKEYv2 IPsec management interface. It may be
available in future versions.
* Alternate name is now consulted to match with
the ID payload.
* Improved DN management (subject name and issuer
name). Now they are shown propertly.
* Lot of bug fixes.
* Addded support for BTNS in the configuration file.
* PFKEYv2 is not available in this version, so if you want
to use it ,keep using 0.93 version (and 0.3 library
versions).
* Addapted to the new libopenikev2 an libopenikev2_impl
API (0.4 version).
* tests 0.4
* Changed in order to be compatible to libopenikev2 and
libopenikev2_impl 0.4 version.
See the libopenikev2 ChangeLog, the libopenikev2_impl ChangeLog,
openikev2 ChangeLog and test ChangeLog to see a more complete change
list. Remember to make backups of the configuration files before install
the new release. They will be overwritten.
You can download it here
_______________________________________________
openikev2-announce mailing list
openikev2-announce at dif.um.es <mailto:openikev2-announce at dif.um.es>
https://correo.dif.um.es/cgi-bin/mailman/listinfo/openikev2-announce

------------------------------------------------------------------------
_______________________________________________

Stephen Kent

2007-07-27 18:18:49 UTC

Post by Yoav Nir
Hi.
Thought this would be of interest to the list.
Apparently they have BTNS support.

Since no BTNS documents are final yet, the above statement seems a
bit premature :-).

Steve

Yoav Nir

2007-07-27 21:55:15 UTC

As long as it's running code...

We've had IKEv2 interoperability workshops months before RFC 4306.

There are also lots of implementations of SCEP and that hasn't made
it to historic yet.

Post by Yoav Nir
Hi.
Thought this would be of interest to the list.
Apparently they have BTNS support.

Since no BTNS documents are final yet, the above statement seems a
bit premature :-).
Steve

Stephen Kent

2007-07-30 14:58:54 UTC

Post by Yoav Nir
As long as it's running code...

Windows is running code too, but it's not an IETF standard :-).

If CheckPoint wants to declare something it implemented as being
BTNS, despite the lack of an IESG-approved document, and in light of
the ongoing changes to the document, I guess it's a good marketing
ploy, if not good IETF behavior.

Post by Yoav Nir
We've had IKEv2 interoperability workshops months before RFC 4306.

Before the RFC was issued (after several months in the RFC Editor's
queue), or before the document was approved by the IESG?

Post by Yoav Nir
There are also lots of implementations of SCEP and that hasn't made
it to historic yet.

That's an irrelevant example, i.e., a protocol developed outside the
IETF which may be published as historic, as a compromise.

Steve

Nicolas Williams

2007-07-30 16:00:10 UTC

Post by Yoav Nir
As long as it's running code...

Windows is running code too, but it's not an IETF standard :-).

Implementations aren't, though they might be standards compliant, but
since the IETF doesn't have any sort of compliance testing, compliance
is up to the vendors to test for and up to the customers to test for and
insist on.

Post by Stephen Kent
If CheckPoint wants to declare something it implemented as being
BTNS, despite the lack of an IESG-approved document, and in light of
the ongoing changes to the document, I guess it's a good marketing
ploy, if not good IETF behavior.

It happens a lot in the IETF. For at least some Internet protocols
vendors have shipped long before the RFCs issued.

In any case, the latest release of the particular implementation that
we're talking about is labelled as version 0.4, which might well be, for
all we know, an acknowledgement of the potential for backwards
incompatible changes as Internet-Drafts change backwards incompatibly.

Nico
--

Stephen Kent

2007-07-30 16:30:02 UTC

Post by Yoav Nir
As long as it's running code...

Windows is running code too, but it's not an IETF standard :-).

or to have third-party labs validate.

It happens a lot in the IETF. For at least some Internet protocols
vendors have shipped long before the RFCs issued.

note my distinction between RFC issuance vs. IESG approval. Once the
IESG approves a document is may take many months (it used to be as
long as a year) for the RFC to be issued, but the substance of the
standard is fixed.

Steve

Nicolas Williams

2007-07-30 17:00:42 UTC

Post by Nicolas Williams
It happens a lot in the IETF. For at least some Internet protocols
vendors have shipped long before the RFCs issued.

Yeah, but with SSHv2 the implementations existed and shipped long before
the I-Ds even passed WGLC.

Stephen Kent

2007-07-30 17:06:41 UTC

Post by Nicolas Williams
It happens a lot in the IETF. For at least some Internet protocols
vendors have shipped long before the RFCs issued.

Yeah, but with SSHv2 the implementations existed and shipped long before
the I-Ds even passed WGLC.

Then the vendors jumped the gun.

Steve

Nicolas Williams

2007-07-30 15:24:49 UTC

Post by Yoav Nir
Hi.
Thought this would be of interest to the list.
Apparently they have BTNS support.

Since no BTNS documents are final yet, the above statement seems a
bit premature :-).

Maybe. There were SSHv2 implementations long before there were SSHv2
RFCs. C'est la vie.

Stephen Kent

2007-07-30 16:09:13 UTC