Paul Hoffman writes: > At 3:55 PM +0300 4/3/09, Tero Kivinen wrote: > >Btw, is there any reason why [V+] is not listed in the IKE_AUTH > >excghange with EAP in the intermediate EAP messages and final AUTH > >request from the initiator? > > We could add it, but I think that would surprise some implementers. > Is it really needed?
I do not think any of the [V+] payloads are really needed, as section 3.12 clearly says that "A Vendor ID payload may be sent as part of any message.". My question was more of "was this omission trying to say something". I.e. does that it is NOT listed in that those messages trying to say that those messages are not logical place for vendor ID payloads. (I actually only now noticed the text about most logical place). I would at least expect that vendor ID payloads could be also used in the last AUTH message from client to server, i.e. after the EAP authentication is finished. The server is already marked so that it can use [V+] in its last response. I.e. for server the logical places are first and last response, but for client the only logical place listed is the first request, last request was ommitted. I agree that during the EAP exchanges itself (the ones repeted 1..N times) the vendor ID payloads might not be that logical (as most likely all extensions during that is done inside the EAP messages itself, not as IKEv2 vendor ID payloads). But I think the last request is bit different case, and I myself consider that as one that could be logical place for vendor ID payload for some extension. Currently it is bit funny that only places where vendor ID payloads are not supposed to be most logical are: - IKE_AUTH exchange with EAP: EAP payload request - IKE_AUTH exchange with EAP: EAP payload response - IKE_AUTH exchange with EAP: last request from client - CREATE_CHILD_SA for Child SA: generic error case response - INFORMATIONAL exchange: request - INFORMATIONAL exchange: response It is not very "most logical" locations if it is listed in 71% of cases (i.e. 15 packets out of 21). I think the most logical place currently to send those vendor ID payloads is only during IKE_SA_INIT exchange request, and IKE_SA_INIT exchange normal response. We currently do not have any extensions which would send them in any other locations, and I have not seen any implementations sending them in any other locations yet. If you want to pick the "most logical" place, then I would only put it on those exchanges, and say that they can still be part of any other message too if needed. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
