Hi Toerless, > > I still have an impression that this can be achieved without adding TA to > > the CERT payload. > > For example, the last cert in the path before the TA will have an Issuer DN > > of TA, so you'll have some information anyway... > > Ok, so the ask to include TA cert into the signaling was raised by Mcr fairly > late in the process, so from that side, i could argue it's too late and this > discussion here is holding back the ACP draft too much. > > Then again, i spend probably a lot of time in labs and with customers > troubleshooting in networks ACP and other IPsec > security-association/certificate > issues because of the security associations, so the need for actually > STANDARDIZING diagnostic capabilities is really dear to my heart, > and given how i didn't dare to bring it up, but Michael did, he has to call > timeout. And given how this is an OPS area document we should think it > is important.
Well, this is the essence of my concerns: it seems to me that the issues you describe are not explicitly anima related issues, instead they are generic IPsec misconfiguration issues. If you believe they are so important, then they must be addressed in the ipsecme WG, and not by profiling IPsec explicitly for anima. (Unless I'm missing something about specificity of these issues for anima). > To your point: I think it is prudent to design a complex system solution > with the best diagnostic we can think of upfront, instead of trying to > add step by step diagnostic only after we have witnessed and tracked > sufficient enough evidence it is needed. I call this the "how many > dead children do we need before we approve the traffic crossing" > problem. I agree with this in general, but in security protocol there is always a tradeoff between better diagnostics and leaking additional information to a potential attacker. Often the latter outweigh. > I think examples of where DN would not be sufficient (and its in the -25 > text) would be expired certs from the correct CA, or certs from > a misconfigured registrar with CA - where the operator unintentionally > re-created a CA with the same DN, instead of going to the correct CA. Expired certs can be detected locally, I don't believe this is a problem (I assume your clock skew is not too large). In case your TA was replaced by the newer cert with the same DN as result of rollover, you'll have the Authority Key Identifier from the last cert in the path, so you'll be able to determine which particular TA with the same DN your peer intended to use... > But that last paragraph made me fall into the trap of me arguing the > names of kids i am predicting to die, and i think thats not how we should > design systems wrt. diagnostics. :-) Regards, Valery. > Cheers > Toerless > > > Regards, > > Valery. > > > > > -Ben > > -- > --- > t...@cs.fau.de _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
