[Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Mon, 12 September 2016 14:28 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: hipsec@ietf.org
Delivered-To: hipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0376412B398; Mon, 12 Sep 2016 07:28:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Mirja Kuehlewind" <ietf@kuehlewind.net>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147369048095.8941.13027964102448014990.idtracker@ietfa.amsl.com>
Date: Mon, 12 Sep 2016 07:28:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/UQ_8Z8HzDiTCOwg80smTLCHCJfE>
Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org
Subject: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?=
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2016 14:28:01 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-hip-rfc5206-bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some concrete comments:
1) Can you further explain the scenario assumed in these sentences! What
is the middblebox supposed/expected to do?
"In this case, the OLD SPI and NEW SPI parameters
       both are set to the value of the preexisting incoming SPI; this
       ESP_INFO does not trigger a rekeying event but is instead
       included for possible parameter-inspecting middleboxes on the
       path. "
and
"An additional potential benefit of performing address verification is
   to allow middleboxes in the network along the new path to obtain the
   peer host's inbound SPI."

2) Section 3.2.1. step 2: I guess the peer would also need to retransmit
the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check
RFC7401...)

3) section 4: Can you give any hints how large the lifetime typically
should be? Can only the original address have an unbounded lifetime (see
section 5) or can I also set the lifetime value in a certain way to
declare the lifetime of this address of unbounded?

4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET
replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST
include all active addresses. I believe that's what you are doing from
the description in section 5 but it's never really spelled out...

5) section 5.4: How long will an address be in UNVERIFIED state in case
the verification is not successful (no reply). Is there a timer? How
often will the peer retry the verification test? How long does the peer
wait until resending the verification packet?

6) section 5.6: The proposed  Credit-Based Authorization  seems quite
complicated for me. First please state clearly the goal: I guess the
scenario is that that you send data to the host and the host switches to
new address. To be able to keep sending data with the same rate during
the "switch-over 3-way-handshake" you need this credit system. So, what
you actually need is to estimate the current sending rate in packets per
RTT and take this number of packets as your credit. If you know the RTT
you can simply count the packets. You can probably always estimate the
RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have
a way to update this RTT estimate during the connection, you might just
use 2xRTT or 3xRTT to be safe...

And more general comments:
1) Did you see any deployment problems because you don't expose a port
number (at a know location above the IP header) with e.g. NATs?

2) Usually documents that obsolete another rfc have a "changes from
RFCXXXX" section. Not sure if this is needed in this case when you move
from experimental to proposed stanadard but given the rather larger
number of changes, I would find it helpful.

3) I believe reading would be easier for me if section 4 would have been
first but not sure...

4) This docuemnt states several times that mutlihoming is out of scope
and only the handover case is described. I think it would be better to
state this clearly at the very beginning and remove the other cases (I
believe these are anyway kind of left-overs from the previous document.)