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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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.




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

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.



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




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


Sure. Will address these comments.

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


Regards
Sri


>
>----------------------------------------------------------------------
>         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
>--
>[e-mail]