Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt

[Tero Kivinen <[e-mail]>]

Sri Gundavelli (sgundave) writes:
> Hi Tero,
> 
> Thanks a lot for the review comments. This is very helpful.
> 
> Please see inline.
> 
> 
> On 4/18/13 2:26 AM, "Tero Kivinen" <[e-mail]> wrote:
> 
> >In section 3 and 4, there is text saying:
> >
> >----------------------------------------------------------------------
> >...
> >   Length (2 octets)
> >      Length of the value field in octets.  In this case, its 4.
> >...
> >   Length (2 octets)
> >      Length of the value field in octets.  In this case, its 16.
> >...
> >----------------------------------------------------------------------
> >
> >But the length of the configuration attribute value can also be 0 for
> >the requests. At least in general case, I do not know whether this
> >P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable
> >option or something else. In normal case the client either sends empty
> >request, and server fills the value in, or the client sends request
> >telling the preferred value, and server either replies with that or
> >something else.
> 
> The goal is to allow the client to request for the configuration value, so
> the server can populate it. So, the client sends a request with a
> NULL/0.0.0.0 value, and the server can include the Attribute with a proper
> value in the response message.

In normal IKEv2 case the configuration payload in that case will be
empty, see RFC5996 section 3.15.1:

----------------------------------------------------------------------
3.15.1.  Configuration Attributes
...
   The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
   information from its peer.  If an attribute in the CFG_REQUEST
   Configuration payload is not zero-length, it is taken as a suggestion
   for that attribute.  The CFG_REPLY Configuration payload MAY return
   that value, or a new one.  It MAY also add new attributes and not
   include some requested ones.  Unrecognized or unsupported attributes
   MUST be ignored in both requests and responses.
...
----------------------------------------------------------------------

It would be better to use same mechanisms for all IKEv2 configuration
attributes, and not make special cases for some attributes.

> >The draft also says:
> >
> >----------------------------------------------------------------------
> >   Multiple instances of this Attribute with different values can be
> >   present in the configuration payload and there is no implied
> >   preferrential order.
> >----------------------------------------------------------------------
> >
> >In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS
> >the multi-valued return values only work in a way, that client sends
> >as many entries in the request as it is willing to get back in the
> >reply, and server can only return as many (or fewer) items there was
> >in the request. This is to allow client to decide whether it wants to
> >support multi-valued addresses. Do you want to do similar thing here,
> >or is it assumed that all implementations do allow multiple values for
> >this attribute? The text from RFC5996 says as follows:
> 
> 
> The client should be able to include a single a instance of the Attribute
> with a value of 0.0.0.0, but the server should be able to offer one or
> more instances of the Attribute.
> 
> In this case, there is no real requirement for the client to indicate
> capability for multiple instances. We can safely assume the client can
> handle one or more values.

Ok, if client is known to be able to handle multiple values, then
there is no need to indicate that by sending multiple requests. 

> >----------------------------------------------------------------------
> >   o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
> >      internal network, sometimes called a red node address or private
> >      address, and it MAY be a private address on the Internet.  In a
> >      request message, the address specified is a requested address (or
> >      a zero-length address if no specific address is requested).  If a
> >      specific address is requested, it likely indicates that a previous
> >      connection existed with this address and the requestor would like
> >      to reuse that address.  With IPv6, a requestor MAY supply the low-
> >      order address octets it wants to use.  Multiple internal addresses
> >      MAY be requested by requesting multiple internal address
> >      attributes.  The responder MAY only send up to the number of
> >      addresses requested.
> >----------------------------------------------------------------------
> >
> >This also points out how the request can either be empty or have some
> >previously used value in. Do you want to do similar thing here?
> 
> The request should be empty. I don't believe ePDG is sending specific
> hints over S2b interface and so we are bound by that interface definition.
> I will check the spec to be sure.

In configuration payload format the empty attribute means that the
attribute length is 0, and the value is omitted, in your case the
attribute length was not allowed to be 0, so the attribute cannot be
empty, but I think it would be better to change it so it can have
length "0 or 4 octects" and "0 or 16 octects", just like all other
IKEv2 Configuration Attributes.
-- 
[e-mail]