Tero Kivinen <kivi...@iki.fi> wrote:
> Daniel Van Geest writes:
>> 1) QS SA Negotiation
>>
>> When negotiating a QS SA, it’s not enough to negotiate QS key
>> agreement algorithm(s), one also has to ensure that the algorithms
>> selected by the other transform types are also QS.
> All of these kind of issues are really policy matters, thus outside
> the PROTOCOL work. I.e., we can add security considerations section
I agree.
> On the other hand this is ONLY needed if the initiator DOES NOT know
> whether other end supports QS or not. Usually initiator can be
> configured to assume either way, it is more important to configure the
> responder so it will accept either QS or non-QS...
I think that one goes around and enables the new QS policy in nodes as one
upgrades them to have QS. An implementation could have a policy knob like:
QS=forbid,accept,propose,insist
(a bit like MUSTNOT,MAY,SHOULD,MUST)
which would add the extra proposals. One starts with "QS=accept" or
"QS=propose", which so that one can interoperate with nodes which have not
yet been upgraded, and then perhaps moves to QS=insist.
I think we are in agreement here, just want to be clear I'm not disagreeing.
One only needs the huge SA_INIT during the transition period between
QS=propose to QS=insist. Still that could be many months to even years.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
