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

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Apr 2013 12:26:44 +0300

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 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:

----------------------------------------------------------------------
   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?

Also in section 5 Example Scenario, it would be nice to have values
filled in to the P-CSCF_IP{4,6}_ADDRESS attributes, just like you have
values filled to other attributes (INTERNAL_IP4_ADDRESS and
INTERNAL_IP4_DNS). I.e. the request is most likely empty and reply
contains something.

----------------------------------------------------------------------
         Client      Gateway
        --------    ---------

         HDR(IKE_SA_INIT), SAi1, KEi, Ni  -->

                  <--  HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]

         HDR(IKE_AUTH),
         SK { IDi, CERT, [CERTREQ], AUTH, [IDr],
              CP(CFG_REQUEST) =
                 { INTERNAL_IP4_ADDRESS(),
                   INTERNAL_IP4_DNS(),
                   P-CSCF_IP4_ADDRESS,
                   P-CSCF_IP6_ADDRESS }, SAi2,
              TSi = (0, 0-65535, 0.0.0.0-255.255.255.255),
              TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }  -->

                <--  HDR(IKE_AUTH),
                     SK { IDr, CERT, AUTH,
                          CP(CFG_REPLY) =
                             { INTERNAL_IP4_ADDRESS(192.0.2.234),
                                              P-CSCF_IP4_ADDRESS,
                                              P-CSCF_IP6_ADDRESS,
                               INTERNAL_IP4_DNS(198.51.100.33) },
                          SAr2,
                          TSi = (0, 0-65535, 192.0.2.234-192.0.2.234),
                          TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }

                    Figure 4: P-CSCF Attribute Exchange
-- 
[email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 21 Apr 2013 20:48:06 +0000

Hi Tero,

Thanks a lot for the review comments. This is very helpful.

Please see inline.

>In section 3 and 4, there is text saying:

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.

>The draft also says:

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.

We did have some discussion on if there is an implied order when multiple
instances of the Attribute or present. In the context of 3GPP interface
where it will be used, the server obtains these Attribute values from the
PGW over S2b interface and there is no such order on that interface. So,
we will not indicate any order, its up to the client on how it decides to
use those values.

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.

>INTERNAL_IP4_DNS). I.e. the request is most likely empty and reply

Sure. Will address these comments.

These are very good comment. Very helpful. Appreciate it.

Regards
Sri

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Apr 2013 15:29:56 +0300

> 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.

> 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. 

> 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.
-- 
[email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 22 Apr 2013 14:26:04 +0000

Hi Tero,

>empty, see RFC5996 section 3.15.1:

OK. This is fine. I will make the change.

>there is no need to indicate that by sending multiple requests.

Ack.

>IKEv2 Configuration Attributes.

Sure. I will make the change to allow empty container.

Regards
Sri