Hi, Tero I realise you are not the one to ask about this, but why not use CFG_SET?
This IMEI information is about as trustworthy as the “APPLICATION_VERSION” type. Yoav > On 15 Dec 2015, at 2:18 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > FYI, I just rejected the DEVICE_IDENTITY configuration payload > attribute request for IKEv2 because of following reasons. > > > From: Tero Kivinen <kivi...@iki.fi> > Subject: [IANA #879113] General Request for Assignment (ikev2-parameters) > Date: 15 December 2015 at 2:15:38 PM GMT+2 > To: iana-prot-param-comm...@iana.org > > > Michelle Cotton via RT writes: >> I'm sending this request to you for expert review. >> If you could reply back before or by 23 November 2015 that would be >> most appreciated.\ > > Sorry for being late for this reply, but I have been quite busy last > few months. > >> On Thu Nov 05 09:32:49 2015, frederic.fir...@etsi.org wrote: >>> >>> Contact Name: >>> Frederic Firmin >>> >>> Contact Email: >>> frederic.fir...@etsi.org >>> >>> Type of Assignment: >>> New item in the "IKEv2 Configuration Payload Attribute Types" of the >>> "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at >>> http://www.iana.org/assignments/ikev2-parameters/ikev2- >>> parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 >>> and updated by IETF RFC 5996 and IETF RFC 7296. >>> >>> Registry: >>> The "IKEv2 Configuration Payload Attribute Types" of the "Internet Key >>> Exchange Version 2 (IKEv2) Parameters" as shown at >>> http://www.iana.org/assignments/ikev2-parameters/ikev2- >>> parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 >>> and updated by IETF RFC 5996 and IETF RFC 7296. >>> >>> Description: >>> This IKEv2 attribute is used to provide device identity. >>> >>> Additional Info: >>> IETF RFC 4306 defines the registry for the "IKEv2 Configuration >>> Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to >>> IETF RFC 4306 for the definition of the registry. >>> >>> The following attribute is requested to be registered: >>> - value: (number to be assigned by IANA) >>> - attribute type: DEVICE_IDENTITY >>> - multi-valued: no >>> - length: 1 or more octets >>> - reference: 24.302 13.3.0 http://www.3gpp.org/ftp/Specs/html- >>> info/24302.htm > > This assignment is problematic. > > If I have understood correclty this will use configuration payloads in > non-standard way, i.e. in way where it has not been used before. > > Normally client requests parameters by sending CFG_REQUEST, and server > replies values back using CFG_REPLY. > > In this case if I have understood correctly the server sends CFG_REPLY > back asking for client provide the DEVICE_IDENTITY. The RFC7296 says > that "In variations of the protocol where there are multiple IKE_AUTH > exchanges, the CP payloads MUST be inserted in the messages containing > the SA payloads." (RFC7296 section 2.19). This means that > CP(CFG_REPLY) is in the last IKE_AUTH, i.e. after the EAP > authentication is finished. > > The 24302-d30 section 7.2 seems to indicate that we send CFG_REPLY > back during the EAP and IKE_AUTH exchanges, and then do second > CFG_REQEST after that. This is against the RFC7296, as the first > CFG_REQUEST already contains the IP-address assingment request, and > its CFG_REPLY MUST be in the last IKE_AUTH. > > Also the DEVICE_IDENTITY is attribute that is flowing in wrong > direction. I.e. the CFG_REQUEST/CFG_REPLY is meant to be working so > that CFG_REQUEST is used by the initiator to request something and > CFG_REPLY is used by responder to reply those configuration > parameters. In this case the responder is requesting the initiator to > provide some information. > > Also DEVICE_IDENTITY has nothing to do with the configurations of the > devices, and is not needed by the IKE or the networks stack to create > the IKEv2 tunnel. It does not belong to the configuration payloads. > > As this is also completely untrusted, and provided just for the > information for the server side, I think it would be better to use > Notify payloads to send this information. I.e. allocate status > notification payload for IMEI and another one for IMEISV, and require > that clients send those notifications during the IKE_AUTH exchange. > -- > kivi...@iki.fi > > > _______________________________________________ > 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
