>> 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. > 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. >> 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.
Regards, Tobias _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
