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

Tero Kivinen <kivinen@iki.fi> Thu, 18 April 2013 09:28 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CE0DD21F894B for <ipsec@ietfa.amsl.com>; Thu, 18 Apr 2013 02:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 314ZvGSjJ1YM for <ipsec@ietfa.amsl.com>; Thu, 18 Apr 2013 02:28:16 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) by ietfa.amsl.com (Postfix) with ESMTP id 9E95421F8972 for <ipsec@ietf.org>; Thu, 18 Apr 2013 02:28:15 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3I9QjYj012582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Apr 2013 12:26:45 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3I9QinG012877; Thu, 18 Apr 2013 12:26:44 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20847.48212.437658.582136@fireball.kivinen.iki.fi>
Date: Thu, 18 Apr 2013 12:26:44 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: noblea@cisco.com, sgundave@cisco.com, jouni.nospam@gmail.com, baboescu@broadcom.com
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 11 min
X-Total-Time: 12 min
Cc: ipsec@ietf.org
Subject: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 09:28:16 -0000

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:

      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]

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

                <--  HDR(IKE_AUTH),
                     SK { IDr, CERT, AUTH,
                          CP(CFG_REPLY) =
                             { INTERNAL_IP4_ADDRESS(,
                               INTERNAL_IP4_DNS( },
                          TSi = (0, 0-65535,,
                          TSr = (0, 0-65535, }

                    Figure 4: P-CSCF Attribute Exchange