Hi Paul,
thank you for clarifications. One more point. The draft is silent about
what the responder is supposed to do with the stream prefix.
Should it check it? In this case what should it do if the prefix is
different from "IKEv2"? Discard the TCP session? Or should
it ignore the prefix completely? In this case how many bytes
should it skip from the beginning of the stream - exactly 5?
That might not work well if we get IKEv2.1
That was the point. But please see below.
Actually, I'd argue it should be a unique identifier but not contain a
verion number of the IKE protocol at all.
Not sure. Actually, this prefix is meaningful only for middleboxes,
so it is not linked with any particular IKE version and can be an arbitrary
string,
that is different from TLS ClienHello and other existing prefixes Yoav
mentioned.
On the other hand the prefix can be used as an indication of teh encapsulation
format. For example, in the unlikely event we later want to change length field size
to 4 bytes, we can change the prefix to distinguish between old and new formats.
In this case the responder should discard the TCP session if
the prefix doesn't match an expected value, since it means
that the encapsulation format is different from what it understands.
But my point was that in any case - whether the prefix should be checked or
ignored
by responder, - the behaviour must be clearly described in the draft.
Paul
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
