Hi Paul, > > 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. > > I would think it quite differently. Each protocol extension just puts > payloads in the IKE_SA_INIT and once that one becomes too big, the > IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. > This document defines what goes into IKE_SA_INIT, so the rest (eg new > stuff) ca ngo into IKE_INTERMEDIATE.
>From implementer's point of view it's better if the possible content of each message be clearly defined. It simplifies parsing message and state machine... > > I think that corresponding application document must define this. > > I don't see why they would need to do that? For example, imagine I > add a large notify payload that would cause IKE_SA_INIT fragmentation, > the IKE daemon looks what payloads to put in IKE_SA_INIT and the > non-listed Notify payload would be put into one or more > IKE_INTERMEDIATE exchanges. I don't see any problem here. You can write an application document saying that once INTERMEDIATE is negotiated (and some other thing happened, indicating mutual support for the following), the peers may offload there whatever they want (and makes sense) from IKE_SA_INIT. I just don't want such things take place sporadically, by sole fact that INTERMEDIATE is supported. Otherwise Tobias G.'s concerns are applied. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
