[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] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)
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.)
- [Hipsec] Mirja Kühlewind's No Objection on draft-… Mirja Kuehlewind
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Robert Moskowitz
- [Hipsec] Mirja Kühlewind's No Objection on draft-… Mirja Kuehlewind
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Tom Henderson
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Mirja Kühlewind
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Tom Henderson
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Mirja Kuehlewind (IETF)
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Tom Henderson
- Re: [Hipsec] Mirja Kühlewind's No Objection on dr… Robert Moskowitz