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