Yaron Sheffer writes: > It seems to me we are adding architectural assumptions,
Not really adding architectural assumption, but just explaining that in those cases we do not need QCD, as we have more efficient already standardized ways to handle the situation. > just to gain a relatively minor simplification of the protocol. Not > a very good trade-off. I do not really consider the simplification a minor. When you have protocol which allows lots of options it gets much more complicated to write the implementation and especially test all possible combinations. What I was proposing that if only the initiator can act as token taker and responder can act as token maker, then that removes lots of different combinations: Otherwise the initiator can act as token maker or token taker or both, and it might also receive token or might not receive token. Same thing for responder, and you need to combine all possible combinations: 1) I token maker, R token maker 2) I token maker, R token taker 3) I token maker, R token taker and maker 4) I token taker, R token maker 5) I token taker, R token taker 6) I token taker, R token taker and maker 7) I token taker and maker, R token maker 8) I token taker and maker, R token taker 9) I token taker and maker, R token taker and maker (yes, some of those combinations are no-ops, like 1 and 5). And then you also have similar setup for rekeying, and similar setup for recovery. What I was proposing you have: 1) I token taker, R token maker I do not consider very open protocols which allow all kind of things "just for fun" and "in case we someday get scenario which can use it" as good thing. Even if those are allowed in the protocol, nobody is going to implement those combinations, thus when someone then thinks a scenario where they might be useful, the implementations need to be modified anyways to support that, and most likely what happens is that we need to specify something new because we cannot break old implementations by using features they have not implemented. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
