Yoav Nir writes: > I realise you are not the one to ask about this, but why not use > CFG_SET?
Mostly, because it is not a configuration information, and what would be the meaning when the server does not ACK your DEVICE_IDENTITY. Also I do not know any implementations that actually supports CFG_SET / CFG_ACK. And I think they want to get that during the IKE_AUTH, and they are already using CFG_REQUEST and CFG_REPLY to get the IP-address etc, so mixing two configuration payloads inside IKE_AUTH during EAP authentication would be quite confusing. I.e. what they propose doing now is: HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT+,] AUTH, CP(CFG_REPLY), EAP } HDR, SK { EAP } -> <-- HDR, SK { EAP } HDR, CP(CFG_REPLY), AUTH --> <-- HDR, SK { AUTH, CP(CFG_REPLY), SA, TSi, TSr } or something like that, i.e. the first CFG_REPLY says that return DEVICE_IDENTITY, and then there probably needs to be second CP to get the actual IP address or something. The text in their documentation does not really tell how it is supposed to work. > This IMEI information is about as trustworthy as the “APPLICATION_VERSION” > type. Yep. I.e. it is whatever the client software or user decided to configure there. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec