Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

[Tobias Heider <[e-mail]>]

>>>> 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