> > 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. > > > I like that idea actually. It would be nice though to have some fixed > order for > additional payloads, as we always had a fixed order for expected payloads.
IKEv2 has no restrictions on payloads order. > >> 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. > Indeed. > I think the main advantage of IKE_INTERMEDIATE could be that specific > "users" would not have to take care of this in their documents because it is > solved once in a generic way. True. Besides specification, there is an advantage that a single piece of code will take care of some INTERMEDIATE core functions (like its authentication etc.) Regards, Valery. > Regards, > Tobias > > _______________________________________________ > 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
