On Mon, Jun 22, 2020 at 05:51:16PM +0300, Valery Smyslov wrote:
> Hi Ben,
>
> > It's not quite "you know who you are talking to based on IP", but more of
> > "under this precondition, you know that the peer should be part of the same
> > ACP domain, and thus using the same TA as you". But you don't know exactly
> > which peer in the domain, and thus which EE cert, you're going to get.
> >
> > The case that (IIUC) triggered this subthread is when things are wired
> > badly and you end up actually talking to someone in a different ACP domain,
> > i.e., with a different TA. We want to be able to report what that
> > "unexpected" TA is, so that the mis-wiring can be diagnosed more readily.
>
> 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.
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 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.
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.
Cheers
Toerless
> Regards,
> Valery.
>
> > -Ben
--
---
t...@cs.fau.de
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
