Hi Tero, > > You can solve the problem of imperfect error handling by adding a new > > SECLABES_SUPPORTED notification, that must be exchanged in > > IKE_SA_INIT. If both peers support seclabels, then the responder must > > not ignore seclabel notifications in IKE_AUTH and CREATE_CHILD_SA. The > > drawback is that we need one more notification and it must be > > exchanged in IKE_SA_INIT, increasing its message size. Not a big deal. > > I am not sure we need that. I mean if initiator do require security labels and > sends security labels notification, but responder does not reply to them, what > can it do next? There isn't going to be any communications between the peers > in that case, so it should simply tear down the SA anyways.
The SA won't be created in this case, since the initiator stopped creating it by not initiating IKE_AUTH. > If it gets same information during IKE_SA_INIT (missing > SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is not > authenticated, so it will need to run IKE_AUTH to the end anyways to make > sure that there was no attack removing that SECLABELS_SUPPORTED > notification. So it will detect that error at the end of IKE_AUTH always. Well, the situation is no worse than with NO_PROPOSAL_CHOSEN or with USE_PPK. In brief - if an attacker is so powerful, that it can remove packets from the network and replace them with forged ones, then it can break communication anyway (just drop all packets). On the other hand, if an attacker can only inject packets, then the responder's packet will eventually reach the initiator. In our case the strategy for initiator is: retransmit and wait. If even after several retransmission it doesn't receive message with SECLABELS_SUPPORTED, then there is no reason to continue with IKE_AUTH (if using labels is mandatory for initiator). If it receives a message with SECLABELS_SUPPORTED, then go with it. Regards, Valery. > In that case there is no point of adding notification to the IKE_SA_INIT. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
