>>>> If there is a chance that this is a potential thread (and I >>>> fear >>>> it'll be impossible to proof the opposite), my feeling is >>>> that the document should say that IKE_INTERMEDIATE MUST NOT be >>>> supported without the support of at least one document defining >>>> the payload. >>> That is implied. I can make this more explicit, by adding >>> something like that: >>> >>> Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED >>> notification only confirms that both parties support >>> INTERMEDIATE exchange. It is not enough condition to start doing >>> INTERMEDIATE exchange. A separate documents that utilize this >>> exchange MUST define the conditions in which peers would do >>> INTERMEDIATE exchanges, the conditions for ending the sequence of >>> these exchanges and start IKE_AUTH, and the payloads these >>> exchanges should carry. >>> >>> Is it OK for you? >> I was wondering about what happens when multiple documents utilize >> the IKE_INTERMEDIATE exchange at the same time. Can two different >> documents utilize a single exchange of IKE_INTERMEDIATE messages, >> or must every document add an additional exchange of >> IKE_INTERMEDIATE messages? > > It's a good question. My idea is that each application document must > define this, as well as the order of INTERMEDIATE exchanges, if it > matters. So, I assume that by default each application will utilize > its own INTERMEDIATE , but some applications could benefit from > piggybacking. But this must be clearly described in corresponding > document In that case, wouldn't it be better to not have a single IKE_INTERMEDIATE exchange type ID but one for each document and use-case. That way an implementation could easily check the exchange type, check if the SA is in a state to accept this specific type of exchange, and then check if the exchange type and contained payloads match. IMO this would allow packet handling and parsing implementations a lot more robust and allow to filter corrupt/unexpected packets early.
>> Currently the only "user" is the Hybrid PQKE draft which adds up >> to seven >> INTERMEDIATE exchanges before the IKE_AUTH, could i just >> define a draft that includes an additional payload in the first >> INTERMEDIATE exchange (not knowing whether Hybrid KE is used or >> not) or would i have to add an eighth INTERMEDIATE exchange? > > I think that corresponding application document must define this. > QSKE exchanges would most probably take place before any other > INTERMEDIATE exchange, since they update the keys and increase IKE SA > protection, but again, it must be defined in the application > documents. >> I couldn't find any info on this in the current draft and i feel >> like this is quite relevant for future users of the exchange. > > I don't think it must be defined in this draft. Instead, it must be > defined in the documents utilizing this exchange. Note, that these > documents will appear one by one, so every next published document > must have a section describing how this application of INTERMEDIATE > should deal with the already defined applications (whether it is OK > to combine payloads or not, what is the relative order etc.) Then we must be incredibly cautious that every document using IKE_INTERMEDIATE specifies explicitly what happens if other known users are used in conjunction, as well as what happens for every possible combination of other known users. If one document for example would specify to always be the first INTERMEDIATE exchange, it would block any following document from doing the same without losing compatibility, as there clearly can't be two first INTERMEDIATE exchanges. In that case, isn't the effort of having to explicitly specify every single case actually the same as if every of these documents would simply specify it's own exchange that takes place between IKE_SA_INIT and IKE_AUTH? What is the advantage of using INTERMEDIATE then, instead of just rolling your own solution? Regards, Tobias
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec